[X3D-Public] interest in network sensor / client based server software

Christoph Valentin christoph.valentin at gmx.at
Wed Jan 8 11:59:52 PST 2014


> > another two cent (I know, I am carrying coals to Newcastle)
> No apologies necessary - we love your coal here.
[Christoph:] Thank you, that's inspiring to me :-)

> > maybe starting with requirements:
> >
> > What could the requirements look like? (just a suggestion, not a proposal)
> >
> > a) A model can run in different MU scenes from different authors without change
> > b) Usage of a scene can be restricted to subscribed scene users
> > c) Usage of a model can be restricted to subscribed scene authors
> > d) Usage of a model can be restricted to subscribed scene users
> > e) A multiuser session can simultaneously run on different Web3D Browsers for different users
> > f) ....and so on
> 
> When I was thinking about these different scenarios, I thought for different apps you'd want something different, or perhaps whoever starts a new empty world could decide and more flexible apps could pick up on it parametrically rather than hard coding it. I called it 'publish/subscribe policy'. I was thinking it wouldn't be 'secure' and enforced against intruders, but rather each peer/client would enforce the policy on itself. Lets say a peer publishes a content but without interactivity attribute. The subscribing client would still get the sensor nodes, but when rendering the scenegraph for that content, would check the content flag for interactivity and if false then don't allow the client avatar to click it.


[Christoph:] This way, the publisher of the content must rely on the Browser enforcing the policy. If I were a publisher, I would probably trust the server that manages my content, but I would never trust any browser.
Maybe better: Modifying the content on server side and downloading only the features of the content that are approved by the policy


> 
> You have scene and model and you mentioned modules before. So there are different possible granularities of publish/subscribe content aggregation. I was thinking of course granularity - content unit ~= web3d scene file - for easy coding in freewrl. But perhaps it could work like nested nodes in a scenegraph: each node inherits publish/subscribe attributes from parent node.


[Christoph:] A few words about "modules", as I defined them in the experimental SMUOS Framework.
   A module is "something" that provides a minimum interface (specified fields) and that contains
   and initializes an instance of the "Module Coordinator" (X3D prototype)
   The Module Coordinator coordinates all MIDAS Objects of a module
a) I came to the idea of modules, because model railroads are sometimes built by modules, too.
   Each module can be provided by a different person and sometimes the model railroaders gather and
   plug there modules together.
b) Same idea here: each module from a different author, modules can be "plugged" together by person
   who provides the overall scene to their users.
c) Person, who provides the overall scene to their users, has to set "moduleName".
d) Models contain MIDAS Objects for instrumenting the functionality (e.g. steering of a car)
e) MIDAS Objects contain Network Sensors
f) stream Name of Network Sensor (necessary for identification on the net) is derived from 
    moduleName + objectId
g) A scene is restricted to the "MMF-paradigm" (model / module / frame)
     scene 1:1 frame 1:N module 1:N model
h) future idea (not yet implemented) "Moving Modules":
     enable modules being parts of models
      scene 1:1 frame 1:N module 1:N model 1:N module 1:N model 1:N module 1:N model ad inf.
   this future idea necessary for train ferries, turntables, "model railroad in the model railroad"

> 
> > regarding Synchronization:
> > Maybe taking a step back and thinking "what would be, if we had no DIS, no Network Sensor"
> >
> > Option A) Avoid differences between single-user-scenes and multi-user-scenes
> 
> - a course-granularity content aggregation could apply publish/subscribe attributes to a scene-file-level aggregation, and the scenefile itself would look the same, except the code guts of the browser would get the attributes during subscription, at one-higher-level in the technology stack.
> This would hide the details of synchronization which would mean they aren't a standard in the x3d scene description. So either different browsers wouldn't cooperate, or a separate standard for MU sync, publish/subscribe etc could be needed.
> 
> > Option B) Provide special means for multi-user-scenes
> >
> > ad A) X3D Time Sensor, Collision Detection, ..... maybe could be defined for "native" multi-user-mode
> > ad B) use X3D DIS, network sensor, ..... maybe improve them
> >
> 
> I don't have enough experience with MU to have ideas at this level - no neurons fire.
> 
[Christoph:] I would prefer option B, not only because I already did it this way, but because this option leaves more freedom to the scene author / model author (on the other hand, it's not "easy-to-use")





More information about the X3D-Public mailing list