10 12 13 14 1s. is 0 1s 13 20 a1 22 23 24 25, 26 27 28 23 30 BL 32 34 35 36 37 38 39 40 41 42 43 4a 45 46 a7 48 49 50 51 52 53 54 55 56 57 58 59 60 62 62 63 Yi\Shared\In-House\Projects\dvginterfaces\dvginterfaces\Interfaces\Payload\IRoot .cs using System; using [Link]; using [Link]; using System. Text; namespace dvginterfaces. Interfaces. Payload { interface IRoot u uv " us " “ uv "7 u“ ue u" uy ue us u" u" uw ue uw "4 uy us we “ uy We we WW Wy Ww we uw Ww Wy wv W uy W Manages a sub-graph. There may be many sub-graphs, and each of then should ("must") have a root af a parent. The root node contains data that is necessary for all proper distributed management of the grapn. Thus, for proper graph management, the root node is 4 very important piece of information for callers. The root node shall manage issues such as these: 1. Storing the allocated/free/next available ID numbers (so that clients can reliably issue 1Ds) 2. Maintaining proper child list of all nodes, to ensure that all children of the graph are reachable from a root node (otherwise, there is no way to relate a child to its parent) 3. Provide graph-oriented locking (for modification purposes) . May later allow locking of sub-graphs, but in order to provide a single point of locking (a la table lock in SQL), the root node provides the ideal starting point. Tt may contain custom locking data structure (because all publishing proxies nay not have object locking capabilities). So, in this way, we can do distributed transactions on the graph, by doing the locking on the root node. This will be inefficient if we have a single root with a lot of sub-graphs, so such locking mechaniens may need to be delegated to folders/models, but it is an excellent starting point for providing integrity/transactions and thus moving towards providing ACID properties (atomicity, Consistency, Isolation, Durability) Notably, Consistency. Isolation is’ tricky, unless we lock individual nodes. 4, Be quickly queryable, so that clients that connect to a proxy can immediately see all roots. ‘The root list cannot be hierarchical. Tt is similar to a list of databases on a database server, or folders in a root of a drive, or list of drives on 4 computer (regardless whether denominated by letter or string). The number of root nodes must be reasonable. Too many root nodes indicate that multiple proxies may have to be used. Root nodes may have to be unique types in a space, so that we do not have to iterate all nodes to find them, just for the sake of quick retrieval. It is unfeasible to traverse hundreds of thousands of nodes, even linearly in chunks, and even without deserializing and inspecting the payload, in order to find the root. 5. May contain references to important usage documentat, owner, news, etc. that callers shall always see when starting to traverse the graph. Ln az 3 4 ¥:\Shared\In-House\Projects\dvginterfaces.. . \Interfaces\Payload\[Link] using System; using [Link]? using [Link]; using System. Text; namespace dvginterfaces. Interfaces. Payload { interface ISelection ‘ // identities of one or more selected nodes, // which may be groups or leaves.¥:\Shared\In-House\Projects\dvginterfaces\dvginterfaces\ Interfaces\Payload\[Link] using System; using [Link]; using [Link]; using [Link]; namespace dvginterfaces. Interfaces. Payload ( interface IFile : Interfaces. IDistributedPayload ‘ “ uv Represents a binary uploaded file Needs to contain file name, user modification data, attributes, checksum, optionally encryption and compression flags. File would then be chunked into sub-regions. Such regions would be child nodes of the IFile node. These are the IFileChunk nodes. The main file node does not contain the data itself, only references to the file chunks. By piecing together the chunks, the complete file can be obtained. Check-sum controls are required both on the overall file and on chunks. 11 2 3 4 5 6 7 8 9 10 a 12 13 14 45 16 uv Y:\Shared\ In-Hiouse\ Projects \dvginterfaces. . .\Interfaces\Payload\[Link] using System; using [Link]; using System-Ling; using [Link]; namespace dvginterfaces. Interfaces. Payload ( interface IFileChunk ‘ // Represents a sub-section (region) of a file, Can be used for 77 streamed query and retrieval (partial) of file, Chunk size // can be customized freely (but should be more than a few hundred bytes). // Chunks need to have their own checksum for reader's verification. 77 Chunks are children of files.¥:\shared\In-House\Projects\dvginterfaces. \Interfaces\Payload\[Link] using System; using [Link]; using [Link]; using System. Text; namespace dvginterfaces. Interfaces. Payload ‘ interface IPropertyset ‘ J/ Represents a list of name-value pairs of specific types. // Not for storing large streams of data, but rather typed // lists of individual values. // Values shall be possible to group (tabs with names). // Tabs don't need any special consideration, except for a name and ID. // Bach property belongs to a tab (or the default tab). // Properties can be of primitive types (int, float, string, bool, // date time, etc) and should be made type safe. // Ideally, we should store name-type-serialized value, and then, // by serializing and de-serializing each property according // to its defined type, we can have type-safe properties of any kind. // ® convenient API can provide easy read/write capability for this.¥:\Shared\In-House\Projects\dvginterfaces\dvginterfaces\Interfaces\Payload\[Link] using System; using [Link] using [Link]; using System. Text; namespace dvginterfaces. Interfaces. Payload ( interface IModel “ Provides the payload for management of a model. Since this is a graph, it is worth to consider what a model actually is here. In this case, a model is the root node for geometry element. It can be predicted that the model should be a placeholder for many pieces of data that will apply to all child nodes (e.g. coordinate system, units, location), hence the model node serves a fundamentally different organization purpose than TFile (since the model may consist of information that is not froma file, or even from multiple files), and is also different from IGroup (we may use groups to balance the graph within IMcdel) and also different from IFolder, since we may have multiple models in a folder. A very important application of IModel for synchronization/refresh~ oriented (repeated) publishing of information from a fixed set of files, is that each IModel can be associated with a physical file name. As long as this file name is unique, we can find which model to synchronize with if we only inspect all models and then map the model's file name property to the file name/path/other identifying data. This greatly simplifies repetitive publishing. 1¥:\Shared\In-House\Projects\dvginterfaces\dvginterfaces\ Interfaces \Payload\[Link] using system; using [Link]: using [Link]; using [Link]; namespace dvginterfaces. Interfaces. Payload 1 interface TGroup { us WW “ uw uy uv uw “uy “ uw 7 “ " u" u uw uw " uw “uw just a way to subdivide the model so that there aren't too many Children in each node (e.g. balancing the tree). May use groups for indexing (e.g. groups of nodes where certain groups should fetch first in streaming) May use groups for controlling sub-graph size, e.g. to prevent a child list (without ranges) fro growing in'a non-scaleable way, we can split it at a threshold. E.g. 64k children max That would be a max of 64x4 = 256 kb node size for the child list alone, since each int is 4 bytes; 256kb is still substantial on very slow connections but still "manageable" This allows scalability of child list size by subdivision. We could optionally attach a bounding box to groups, as they are primarily (if only?) used for geometry subdivision and scalable navigation. Thus, groups can provide the core data structure for nested bounding boxes, Nested bounding boxes can be done by equating one bounding box with each group, and ensuring that the child groups of a group contains bounding boxes that are guaranteed to be inside the bounding box of the parent group(s). This greatly simplifies collision detection, visibility culling, area~of-interest, partial fetch. 1¥:\Shared\In-House\Projects\dvginterfaces\dvginterfaces\Interfaces\Payload\[Link] using System; using [Link]; using [Link]; using System-Text; namespace dvginterfaces. Interfaces. Payload 1 interface IFolder ¢ // Bn organization-oriented data structure. // May allow users to modify folder structure. // Groups, on the other hand, are system-oriented entities // for internal structuring of graph, e.g. geometry groups // or sub-models, or chunk lists. Groups are more oriented towards // efficient traversal, while folders may be redundant in terns of // traversal, but fulfil important user organization functionality. // Folders may allow users to organize higher-level entities, // e.g. models, files, markups, selections, viewpoints, etc., // in a more intuitive, customizable way. // Some user-friendly properties are appropriate, e.g. // creator-user, create-date, name, conments, description, icon, // tags. Folders is the core way for users to organize the graph. // B folder could possibly specify an encryption boundary; e.g // that all sub-nodes would require a particular public/private // key pair for access, or policies for attached child nodes, // e.g. compression policy. However, it is still up to the 71 callers to decide whether to respect this. // Could alse attach a property set to a folder (as a child), by 77 nested payload.¥:\Shared\ In-House\Projects\dvginterfaces\dvginterfaces\Interfaces\Payload\[Link] using System; using [Link]; using [Link]: using System. Text; namespace dvginterfaces. Interfaces. Payload fi interface IIten // ® uniquely identifiable visible item (e.g. that warrants selection) . // Refers to geometry to be instantiated (so that same geometry 77 can be reused and instantiated) . // Provides instantiation matrix (possibly colour). “1 May also refer to 2 property set or file attachnent. // May optionally refer to a markup or other related entities 77 (unless navigation is implicit in other entities), thus, // references other intrinsic data such as property set or // binary attachment may be undersirable, Regardless, this interface “7 does not strictly enforce any such implementation’ style, // since caller can append children freely, and reader will then // find these by means of traversal. 1¥:\Shared\ In-House\Projects\dvginterfaces. \interfaces\Payload\[Link] 1 using system; 2 using [Link]; 3 using [Link]; 4 using [Link]; 5 6 namespace [Link] 7 interface IItenGrid { // Provides repetitive instantiation of iteme // Ttems are mainly for parametric compression and capturing of intent. // We can have a single row (items with fixed spacing), // grid (in a plane) + vector of plane, or 3d-grids (2d + vertical extrusion copies) // Can also add "exceptions" (to remove particular instances) // ems will share properties. “Xi \Shared\ In-House\Project s\dvginterfaces\dvginterfaces\Interfaces\Payload\IMarkup.cs_1 using System; using [Link] Generic; using System. Ling; using [Link]; namespace dvginterfaces. Interfaces. Payload { interface IMarkup t // Refers to mark-up associated with elements. // Typically, the child elements are the elements that have 71 been marked up. // Mark-ups could be organized separately from the geometry // e.g. in its own folder structure. // Mark-up might be a hand sketch, text or some user comment. 7/ One may attach a file to the markup itself (as a child of it). 77 One may mark-up anything (e.g. selection set, view point // can also be marked up).X:\Shared\ In-House \Projects\dvginterfaces\dvginterfaces\Interfaces\Payload\IAvatar.cs_1 using System; using [Link]; using [Link]; using System. Text; namespace dvginterfaces. Interfaces. Payload { interface TAvatar ‘ // Represents an observer/actor in the geometric model. 77 May contain its own rule checks, objectives and constraints. 7] May have its own navigation policies. 7/ May be impersonated by users (as it has its own viewpoint and 7/ camera). Has its own reach (collision detection/distance measure). // May have parametric definition (property set). " "cour¥:\Shared\In-House\Projects\dvginterfaces. \Inter faces \Payload\ParanCurveFragnent..os 1 using System; using [Link]; using [Link] using [Link]; namespace dvginterfaces. Interfaces. Payload ‘ interface IParamCurveFragnent ( // Curve with parametric definition // Will contain driving formula and parameter (s) plus // ability to obtain tesselated result (as ICurveFragment) // Suitable for circle, arc, b-spline, parametric polygon, etc. // Could even represent text, hatch, etc.¥:\Shared\In-House\Projects\dvginterfaces. using system; using [Link]; using [Link]; using [Link]; namespace dvginterfaces { Interfaces. Payload interface ICurveFragment ¢ “ “ “ “ " u" u uv uW u u Ww u u uw Fragment with curve-oriented data. Expected typical content: points (curve with one point), lines (curve with two points), polylines (curve with many points). Ares are better represented as parametric curve fragments if user is allowed to re-style intent (parameters) and expect various precision of tessellation, unless they are not parametric (in which case ICurveFragnent is still appropriate) Basically, 2D~style information (e.g. 2D drawings or sketches) or curves’ used for extruding 3D geometry could be stored as curve fragment. Note that the fragment coordinates shall be 3D vertices. It would be possible to define a triangle as a curve, but since triangles are so common, and this would lead to a lot of indirection and redundancy, notably redundant vertices, there is a separate payload type for triangle fragment. -\Interfaces\Payload\[Link]Y:\Shared\In-House\Project s\dvginterfaces. \Payload\[Link] using System; using [Link] using [Link]; using [Link]; namespace dvginterfaces. Interfaces . Payload 1 interface IParanTriangleFragnent i “uw us u “ u" uv "7 Parametric triangle fragment. May consist of primitives, solids, etc., e.g. CSG. Suitable implenentations of tesseilation could be sgCore, EyeShot solid or even Revit's new Family API. Contains a parametric definition that drives ite generation (tessellation) of triangles. Tessellation shall return an ITrianglefragment.X:\Shared\ In-House \Projects\dvginterfaces...\Interfaces\Payload\ITrlangleFragment.ce_1 using System; using [Link]; using System. Ling; using [Link]; namespace dvginterfaces. Interfaces. Payload { interface ITriangleFragnent // Geometry fragment with 3d information. // Basically a plain set of vertices and trianges (two liste). // Provides an already tessellated representation, ready to // be instantiated.¥:\Shared\In-House\Projects\dvginterfaces. \Interfaces\Payload\ [Link] using system; using [Link]; using System. Ling; using System. Text; namespace dvginterfaces. Interfaces. Payload ( interface IViewPoint i // Represens a view point (camera, orientation, position) in the model. 71 May also contain predefined visibility of specific selection sets.Y:\Shared\In-House\Projects\dvginterfaces.. . \Interfaces\Payload\[Link] 1 ‘typical navigability of nodes, based on payload. Note: other types of navigation can be dynamicaily introduced, as long as the client is able to understand what the navigation means and make use of it. We don't need all clients to navigate and understand all relations. However, if the client expects some child, it should be provided. In case only one child is expected, the word [SINGLE] is used. In case the navigation is done from within the payload (not from the child list of the node header), the word [EMBEDDED] is used. Nothing navigates to Root (expected) From [Root -> [Folder (possible) From Folder -> IFolder (possible, to enable nested folder tree) IFolder -> IAvatar (for generic roles) Ifolder -> IFile (for distributed file system) IFile -> IFileChunk (expected, to segment file into streamable parts) Iavatar -> IPropertySet (SINGLE) (expected; for avatar custom definitions) IFolder -> IModel (expected, to place model properly in an organized way) IRoot -> INodel (possible, but preferably, should use folders) IModel => IViewPoint (to define viewpoints in model) Iodel => ISelection (to define selection sets in model} Selection -> IGroup/TTten (to define selection target) IGroup => IIten (to group geometry) Iitem -> ITriangleFragnent [SINGLE] (to instantiate fragments) 3item -> IPsramfriangleFragnent (SINGLE] -> [EMBEDDED] ITriangleFragment: To instantiate parametric geometry fragments for dynamic tessellation Item -> ICurveFragnent [SINGLE] (to instantiate curves) Titem -> IParamCurveFragment [SINGLE] > [EMBEDDED] ICurveFragnent To instantiate parametric curves (lines, polylines, circles, splines etc) for dynamice tessellation; could also be used in smart compression of solids IGroup -> IItenGrid (to allow repetitive instantiation of items) IitemGrid -> TItem (SINGLE] (to repetitively instantiate an item in arrays of various ¥ kinds, which can drastically compress the model for repetitive placements) Iodel -> IMarkup (to allow markups to attach to model) IMarkup -> IItem (to point markups to items) IMarkup -> 1Selection (to point a markup to a selection, which may contain multiple elements)¥:\Shared\ In-House\Projects\dvginterfaces. ..\Interfaces\[Link] using System; using [Link]; using [Link]; using System. Text; namespace dvginterfaces. Interfaces ‘ interface IDistributedGraph ¢ “us uv “Ww “us uv “ “uv u" uy uv u" u" u uW uw uy Wy Wy W uw uv WwW Provides an interface for navigation of a distributed graph. It should provide acess where children are implicit in each node, thus, no arc list. It should be possible to have clients such as QuickGraph to operate on this graph structure by mapping this Interface to an implementation that exposes an interface that QuickGraph can use. Each distributed graph is made unique based on having a defined Foot node. Due to the requirement of connectivity, it must be possible to navigate to all nodes of the graph by starting from the root node. The system doesn't break if a node is not connected, but such an "orpan" node (node un-reachable from any root) may be occupying/wasting memory. It could be desirable to create such orphans as a part of a transaction, before "hooking up" a sub-graph to make it visible (navigable) froma root. This could be important to prevent partially published models to be seen during modification. Detaching may not be so useful though, since callers who are already navigating in the detached graph will’not be prevented from continuing doing so. We would have to hierarchically (recursively) lock all sub-nodes for this to work. By getting root nodes of providers and inspecting their root node payload, we can actually return a list of distributed graphs fron the proxy -- a very elegant solution indeed.X:\Shared\ In-House\Projects\dvginterfaces\dvginterfaces\Interfaces\IDistributedNode. using Systen; using [Link]; using System, Ling; using System, Text; namespace dvginterfaces. Interfaces { interface IDistributedNode t // The core of the graph definition // int32_1D 7/ S32) Childnist 7/ bool TsChildRanges 7/ Snt32 NodetyperD 7/ snt32_PayloadtyperD // pytel) Payload¥:\Shared\In-House\Projects\dvginterfaces.. . \Interfaces\[Link] [Link]; using [Link]: using [Link]; namespace dvginterfaces. Interfaces { interface IDistributedPayload t // http: //[Link]/wiki/Strategy pattern // Can use Strategy pattern to provide different binary 77 serialization techniques for binary payload, e.g. by having an array // of instances of serializers that implements the strategy interface, 77 yet point to instances of different concrete implementations. Vf This allows immediate lockup (not multiple if or long ease-blocks). // This would require us to have a general, maybe generic, interface unify the implementation of node serialization. // Tt may be possible to fold the payload interface // into the node interface and implement the above pattern 17 in avglib,10 a2 13 a 1s 16 v7 18 13 20 21 22 23 24 25 26 27 Yi\Shazed\ In-House \Projects\dvginterfaces \dvginterfaces\ Interfaces \[Link] 1 using System; using [Link]; namespace dvginterfaces. Interfaces { wt “Ws ws “wi ws wt “wy “i “it uw uw uw

&n abstraction of a published cache for the distributed vector graph. Caller can hook up the cache to one or more proxies. Caller can set different caching policies and memory restrictions. The cache will then maintain best possible trade-off between speed, memory usage, and CPT usage. The cache may Implement various strategies for eviction, read-ahead, write-behind and multiple layers of delegation; either keep in memory, keep on local disk, or fall back to proxy. It may mesure the access time of different methods to determine which methods that give acceptable performance.

interface IPublishingCache // No vendor-specific things here. 7/ Events are important for monitoring. 7/ May allow policy configuration with XML¥:\Shared\n-House\Projects\dvginterfaces. \Interfaces\:[Link] using system: using [Link]; using [Link]; using System. Text; namespace dvginterfaces. Interfaces { wt Ws uw WW Ws WW

Adapter pattern: Wraps the publishing target. Various targets can thereby be adapted to conform to the same interface. Concrete implementations will call vendor-specific API libraries to Provide access to the publishing proxy.

interface TPublishingProxyAdapter ‘ // This is similar to 77 netp://[Link]/wiki/Proxy pattern 77 but the RealSubject does not inherit fron this interface // Rather, it is contained in the Proxy implementation itself. // Primary implementations: GigaSpaces, Perst, SharedCache, NCache, Velocity // The proxy can be anywhere else; the proxy is only an object-oriented 7/ connection to whatever the actual destination or source for access // to published data is. In all cases, the proxy must allow quick access 77 to individual members (on an object basis). Nulti-second latency for // accessing typical individual objects will not likely be acceptable. // Recess speeds of e.g. 2000-8000 objects/second as in GigaSpaces, is V7 more realistic as a tolerable latency. // Core aspects of the proxy: “7 1, Concurrent, shared access 17 2. Target address (1°/URL/space URL/etc) -- a string 17 3. Provider identifier string 1 4. Locking 17 8. Transactions 17 6. Read, Write, Update: rD-based access for various types (generic) 177, Issuing of unique identity numbers 1 8. Bvents with callbacks¥:\shared\In-House\Projects \dvginterfaces...\Interfaces\IPublishingSourceAdapter.cs__1 using System; using [Link]. Generic; using [Link] using [Link]; namespace dvginterfaces. Interfaces { 1)

/// Adapter Pattern: Wraps the publishing source. /// Various sources are adapted to conform to the same interface. /// Concrete implementations will call vendor-specific API libraries /// to provide access to the publishing source. 1

interface IPublishingSourceAdapter ( //nttp://[Link]/wiki/Adapter_pattern Vopject pattern JJ ®rimary implementation; 77 Systen.10, Buzzsax, RFID NavisWorks, Revit, AutoCAD, VectorDraw, // Ysage: Synchronous/Raynchronous On-Demand Publishing 17 Periodic Publishing/Event-Driven Publishing¥:\Shared\In-House\Projects\dvginterfaces. \Interfaces\1PublishingViewportAdapter.ce_1 1 using system: 2 using [Link]; 3 using System-Ling; 4 using System. Text; 5 6 namespace dvginterfaces. Interfaces 74 8 ///

9 /// Adapter pattern: Wraps the viewport 10 /// & viewport 11 ///

12 interface 1Publishingviewportadapter Bf 14 // Primary implementations: XNA, EyeShot, OpenGL, Unity3D, D3DMoblie as 16 // Could also render to 2D drawings by sectioning cuts by extension of viewporte adapter. uv 18 // May also implement alternative viewports, such as schedules, tables, charts 18 1 diagrams. 20 21 ) 22) 23