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

[doug sanden]

->
>>> Would be curious to know about interest in Network Sensor (aka Event Stream Sensor).
>>>
>>> I know the work on Network Sensor is currently stopped (at least in Web3D consortium).
>>>
>>> On the other hand I know Sven-Erik has posted some mails about defining a communication protocol for Network Sensor.
>>>
>>> I know Don cares for DIS.
>>>
>>> I know the product BS Collaborate from Bitmanagement.
>>>
>>> And I know Octaga player did support / supports Network Sensor, but Octaga Collaboration Server is not / was not available as a product.
>>>
>>> Did I miss something?
>>
>>
>> If you're using a conventional browser plugin with SAI, I suspect you can ajax back to home base:
>> client scenegraph -> SAI registered event listener -> html Script node javascript -> ajax POST/GET -> server app -> sockets -> stateful server-side scenegraph server -> sockets -> server app -> ajax response -> html script node callback -> SAI -> client scenegraph
>>
>
> Yes, OK. Only two questions.
>
> 1) Is it possible with this technique, to define arbitrary fields with arbitrary type and name at the "Network Sensor" node? I do NOT mean defining a new "Network Sensor" prototype for each and every model and application, but I mean defining a generic Network Sensor for all use cases.
>
> 2) Is it possible with this technique, to encapulate the "Network Sensor" in a model completely(!), without support by the master scene? E.g. in a model you add by Browser.createVrmlFromURL()?
>
> With a native Network Sensor, this is possible.

Not sure. I don't know the DIS thing but if its a x3d node type, then it will have output fields. And those fields must be X3D fields -- not arbitrary. So somehow in x3d we are used to working within the constraints of x3d field types.

Having said that, I suspect ajaxing would not be automatically general for synchronizing scenegraphs. You'd have to 'know your content' and register listeners.

If you want to load data - lets say for train simulation - how I might do it is to break it down into
A. static scenery geographic tiles
B. dynamic content like trains that move, interactive content that changes state
C. avatars
A. For the static scenery, each tile could have a proximity sensor associated with it. When the avatar enters, then you would update the surrounding tiles. Can you do that with Inlines? probably you can compute a URL based on grid tile number, and fetch the static content the normal way: assign the url to Inline's url field, triggering a load.
C. for avatar, it depends - is it multiplayer? Do the players need to see each other? If so then you would SAI register a listener on proximity sensor, and ajax that with a POST to the server, which would update other clients through waiting ajax callbacks. Otherwise the avatars can stay local.
B. dynamic content - I think you'd need to 'know your content' and register SAI listeners for event-generating nodes that should be updated elsewhere. If you have a script node for moving a train, and it has events out, then to update the train position in other clients you'd register event listeners on that script node events out. 
But what if you do new instances of trains, or new train car prototypes? I haven't thought of all that. Could you Inline new prototypes and instances with url changes passed through ajaxing?
But likely you'd have analogous problems with network sensors.