Difference between revisions of "Talk:Seaside"
Infomaniac (talk | contribs) m (→Notes 19.01.11: typos, punctuation) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
As I understand it, seaside, in its current implementation, is the browser and repository. In other words it is a peer in the peer to peer network and contributes to the dht storage as well as the virtual routing system. I can see how it can also become an http server, acting as a bridge between the peer to peer network and traditional browser clients. However browser users, since they are not using the seaside client, will only be able to consume and contribute content, but will not be contributing storage or routing. What sort of incentives will there be to run the peer to peer client? Perhaps the capabilities offered by the bridge will be limited? | As I understand it, seaside, in its current implementation, is the browser and repository. In other words it is a peer in the peer to peer network and contributes to the dht storage as well as the virtual routing system. I can see how it can also become an http server, acting as a bridge between the peer to peer network and traditional browser clients. However browser users, since they are not using the seaside client, will only be able to consume and contribute content, but will not be contributing storage or routing. What sort of incentives will there be to run the peer to peer client? Perhaps the capabilities offered by the bridge will be limited? | ||
| − | Notes 19.01.11 | + | == Notes 19.01.11 == |
| − | 1. Standardising | + | ;1. Standardising |
Separate functionality of viewer from the viewed data structure. | Separate functionality of viewer from the viewed data structure. | ||
Spilt into a standard ontology for the data, with 3d specific aspects being in a cobalt sub-layer (explain). | Spilt into a standard ontology for the data, with 3d specific aspects being in a cobalt sub-layer (explain). | ||
All manipulation of data is done via an API, so that any user can do all things (non) cobalt user can do. | All manipulation of data is done via an API, so that any user can do all things (non) cobalt user can do. | ||
| − | The viewer (3D) which is separated out, should also have an API | + | The viewer (3D), which is separated out, should also have an API that allows 3D snapshots/video of views to be requested. |
| − | 2. | + | ;2. Classes and instances |
| − | Class/instance relationship - for re-use and templating, inheritance in the normal OO way | + | Class/instance relationship - for re-use and templating, inheritance in the normal OO way. |
| − | We use an instance based paradigm whereby any node can be treated as a class. | + | We use an instance-based paradigm whereby any node can be treated as a class. |
| − | dot files - data | + | dot files - data specific to a particular viewer, such as the seaside application cobalt viewer, maybe a mobile viewer goes in/has context-specific (it's own) nodes available to store its data in without clogging .. exactly equivalent to how applications store data in .dot folder extension, for example /home/fred/.thunderbird |
| − | Workflow and execution (nodal model) - | + | Workflow and execution (nodal model) - |
| + | |||
| + | ;3. The Workflow Interface | ||
| + | |||
| + | The application for how workflows are enabled | ||
| + | This application is a viewer, therefore same functionality made in cobalt | ||
| + | |||
| + | ;4. Unified Ontology | ||
| + | |||
| + | DHT | ||
| + | Eventual consistency | ||
| + | |||
| + | ;5. Our take on time | ||
| + | |||
| + | Shared spectrum and queries | ||
| + | |||
| + | Note: Include a discussion about the Geoscope, scale etc | ||
Latest revision as of 02:27, 19 January 2011
Contents
Integration of Seaside with OpenCobalt
Some questions/thoughts that came to mind that I would like to clarify:
3D
3D comment moved to Talk:OpenCobalt
seaside<-->browser bridge
As I understand it, seaside, in its current implementation, is the browser and repository. In other words it is a peer in the peer to peer network and contributes to the dht storage as well as the virtual routing system. I can see how it can also become an http server, acting as a bridge between the peer to peer network and traditional browser clients. However browser users, since they are not using the seaside client, will only be able to consume and contribute content, but will not be contributing storage or routing. What sort of incentives will there be to run the peer to peer client? Perhaps the capabilities offered by the bridge will be limited?
Notes 19.01.11
- 1. Standardising
Separate functionality of viewer from the viewed data structure. Spilt into a standard ontology for the data, with 3d specific aspects being in a cobalt sub-layer (explain). All manipulation of data is done via an API, so that any user can do all things (non) cobalt user can do. The viewer (3D), which is separated out, should also have an API that allows 3D snapshots/video of views to be requested.
- 2. Classes and instances
Class/instance relationship - for re-use and templating, inheritance in the normal OO way. We use an instance-based paradigm whereby any node can be treated as a class. dot files - data specific to a particular viewer, such as the seaside application cobalt viewer, maybe a mobile viewer goes in/has context-specific (it's own) nodes available to store its data in without clogging .. exactly equivalent to how applications store data in .dot folder extension, for example /home/fred/.thunderbird Workflow and execution (nodal model) -
- 3. The Workflow Interface
The application for how workflows are enabled This application is a viewer, therefore same functionality made in cobalt
- 4. Unified Ontology
DHT Eventual consistency
- 5. Our take on time
Shared spectrum and queries
Note: Include a discussion about the Geoscope, scale etc
