[Fiware-miwi] SceneAPI features: original intent of the EPIC vs . current plans?

[Toni Alatalo]

On 21 Nov 2013, at 07:12, Toni Alatalo <toni at playsign.net> wrote:

just a little afterthought here:

> 2) Direction of the connection: I think for the scenario with a e.g. simulation service we typically do the connection vice versa: expect the outside simulation service to provide a way for the VW system to connect to to get data. For example to integrate a weather forecast visualisation into a scene we’d by default make an app, as in an either server or client side script, which connects to the weather simulation service to get the

In some cases it can be perfectly fine to do vice versa: have the simulation server connect to the main scene / sync server to feed in the simulation updates.

This the current Sync GE techs and plans would already support somewhat ok. For example for the Oulu city service we could run a separate traffic simulation (possible based on real sensor analysis, the university actually already has those traffic monitoring sensors in use in the city AFAIK) server as a Tundra client, for example as a native client where the simulation would be in a plugin. That simulation-server Tundra-client would just connect to the scene server and create and update the traffic entities and that’d all work fine with the existing tech. We’ve actually thought of these kinds of things often, for example Chiru planned testing separate physics Tundra servers this way, and we have experience of this kind of setups with XMPP at Playsign (not using Tundra in that case).

Also in that scenario however it might be easily beneficial to have a small standalone protocol impl lib so that simulation server would not need all of the Tundra framework (with qt and ogre) just to connect to feed data.

On the Javascript side I think we’ll get that with current plans (is a good idea to separate the WebGL & networking parts enough so that making non-webgl clients is simple and normal). But servers typically don’t want to run a browser environment to connect to another server :) (possibly the mocked browser env in node.js might work enough for sync GE though if it provides websockets the same way).

Ludo’s current plan of enabling this with HTTP makes a lot of sense as that’s easy from any environment. It only may miss the realtime / streaming nature called for in the EPIC — that depends on the exact nature of the data & updates and how the visualizations are made etc.
 
> ~Toni

same.