Difference between revisions of "User:Burhop Piccard/Geometry Based Architecture View"
m (→Components) |
m (→Components) |
||
| Line 18: | Line 18: | ||
The components and applications are represented by boxes show the AWG defined components (green, blue, red) as well as 3rd Party applications used for the creation of geometric content (purple). This view shows multiple ways that various tools might interface with the AWG defined architecture. | The components and applications are represented by boxes show the AWG defined components (green, blue, red) as well as 3rd Party applications used for the creation of geometric content (purple). This view shows multiple ways that various tools might interface with the AWG defined architecture. | ||
'''Web Application A''' represents a web based client that can read and write from various persisted geometric data formats. It is able to comunicate with the Agent Domain to upload or download data. For example, it might provide a way to upload obj, collada, JT or other data formats into the Agent Domain. | |||
'''Web Application B''' represents a web based client with no persistant storge. It might be a web Application that creates geometry and stores it in the Agent Domain. For example, it might create a cube, combine it with pictures from Flickr and upload a "picture cube" to the asset server. | |||
'''Application C and D''' represent applications (new or existing) that comunicate directly with the Agent Domain. For exmaple, these might be programs like Maya, Blender, 3D CAD applications or user created tools. These applications might connect directly with the Agent Domain but it is expected A client side library would be created to handle the common marshalling/unmarshalling of data that is common for these tools. | |||
'''Plugin E''' Is a tool | |||
=Third Party Components= | =Third Party Components= | ||
Revision as of 16:25, 30 October 2007
Overview
Communication
Communication between components is represented by red arrows. This is expected by be carried out by a internet based Rest protocol and defined by the AWG.
The requirement from the geometry perspective varies depending on the path. Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity.
Communication with the viewer requires minimum latency and greater control of the input stream. Initially, the protocol needs to support existing Second Life Geometry (Prims, sculpties) but needs to be extendable to new SL data types as well as External data types.
Components
The components and applications are represented by boxes show the AWG defined components (green, blue, red) as well as 3rd Party applications used for the creation of geometric content (purple). This view shows multiple ways that various tools might interface with the AWG defined architecture.
Web Application A represents a web based client that can read and write from various persisted geometric data formats. It is able to comunicate with the Agent Domain to upload or download data. For example, it might provide a way to upload obj, collada, JT or other data formats into the Agent Domain.
Web Application B represents a web based client with no persistant storge. It might be a web Application that creates geometry and stores it in the Agent Domain. For example, it might create a cube, combine it with pictures from Flickr and upload a "picture cube" to the asset server.
Application C and D represent applications (new or existing) that comunicate directly with the Agent Domain. For exmaple, these might be programs like Maya, Blender, 3D CAD applications or user created tools. These applications might connect directly with the Agent Domain but it is expected A client side library would be created to handle the common marshalling/unmarshalling of data that is common for these tools.
Plugin E Is a tool
Third Party Components
Persistant Storage
Viewer
