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

GLG info at 3dnetproductions.com
Thu Jan 9 02:36:08 PST 2014

Just a simple reminder. You can begin giving your 
X3D world multiuser features almost instantly. Extended
feature set and customization are also available.



-----Original Message-----
From: X3D-Public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
Christoph Valentin
Sent: Wednesday, January 08, 2014 3:00 PM
To: doug sanden
Cc: x3d-public at web3d.org
Subject: Re: [X3D-Public] interest in network sensor / client based server

> > 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
> >
> > a) A model can run in different MU scenes from different authors without
> > 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

[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
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
> - 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")

X3D-Public mailing list
X3D-Public at web3d.org

More information about the X3D-Public mailing list