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

[Toni Alatalo]

Hi again,

am just wondering about Lasse’s SceneAPI plans — the features in the roadmap now, what was planned for it originally and especially how we learned in the F2F meet that we had actually misunderstood the intent of the original EPIC in the call earlier.

We discussed the matter some days ago (late last week?) on IRC with at least Lasse and I think were and are on the same page now about the original intent as how Philipp described it in the F2F.

It seems to me that the current feature descriptions reflect that new understanding so that they are perhaps kind of adapted towards that goal?

However they still stick with the original plan of implementing a server side REST HTTP API.

I’m not sure that is actually the way to go with this GE at all, for two reasons:

1) Protocol: The call is for low latency and high performance, quoting the EPIC: "Such updates to the UI have the user in the loop and thus have to happen in real-time with low latency. Because they may also involve the transfer of large amounts of changed scene data, a high-performance service implementation is critical for many applications.” That is what the Sync GE is for and (possibly) not what HTTP delivers. http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Epic.AdvUI.AdvWebUI.SceneAPI

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 raw data and implements the visualization in itself (for example includes a set of shaders for drawing heatmaps, wind directions & strenghts and different types of rain & feeds that with the data). That’s similar to how we integrate POI and GIS but with realtime streaming of the simulation data as described in 1), instead of HTTP transactions of static data which is the case with POI & GIS. 

So the question is: is the proposed HTTP access to a Tundra scene necessary at all? These features: 
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Feature.MiWi.Synchronization.SceneAPI.SceneAPIQueries
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Feature.MiWi.Synchronization.SceneAPI.SceneAPIManipulation

I understand that this point it is perhaps simpler to go with what the plan has been so far — that’s how it was described in the plan made in spring and later in the arch diagram reviewed in the July Winterthur meeting etc.

Also it can well be that a REST API to Tundra is useful to enable all sorts of simple clients, ranging from custom apps and scripts (e.g. some bot-like server or even a modeling app like Blender, or some web page). So that HTTP SceneAPI idea can be good but not for the EPIC where it originated from (I think due to our misunderstanding, we took the ‘web service’ from one sentence there too literally to mean http).

However, if the sync GE is what actually provides what the envisioned simulation service connectivity would need then it’d be worth a check how the scenario would work with that and what’s possibly missing .. and could hence possibly be the actual work that would be needed for this EPIC. For example the scenario in 2) we can not currently implement on the server side as a Tundra server can not open Tundra (i.e. Sync GE) connections to other servers. In the web client it would work, it’d just have multiple websockets open to both the world & the simulation servers (and also for native Tundra there is a branch for client side multiconnection support, demonstrated with tabbed browsing & very cool Portal functionality where a portal in one scene shows a live connection to another server). Also, it would not be very easy for the simulation service to provide a Sync GE service endpoint as the protocol is implemented in Tundra’s protocol module which currently only works inside the framework there. So one activity could be refactoring the kNet-using TundraProtocolModule to something that be could also be used as a simple lib to add Sync GE support to any service (a minimal deps c(++) lib is easy to wrap as a node.js plugin or in some .net or python web service framework for example).

We’ll actually meet with Lasse and some others in the afternoon (for the continuation project plans) and probably discuss the on-going sync GE + entity system + 3DUI integration work again too, can probably talk about this SceneAPI as well. If Philipp or Christof or someone has insight on how to best go about this now please tell so we can consider it. 

Easiest I think is to go with the plan and Ludocraft has already invested planning etc. for it so I don’t know if it’s even possible to change anymore. 

However as AFAIK no implementation work has been done for it (apart from the websocket implementation on the server and the same lib would be used for plain http too) so may be possible to change plans if it’s beneficial. Sync GE is now getting there in any case and if also this EPIC is better delivered with it then perhaps it’s good that Lasse could focus even more on it and ignore the http part? (which is simple to add later if we need it for other reasons, also at Playsign we’ve implemented http endpoints in Tundra earlier for simple still image based cloud rendering needs to control the camera from a browser GUI etc).

~Toni

P.S. very cool to see this on the table - can be related too if this adds the capability for Tundra servers to connect with each other, part of the func noted missing for scenario in point 2) above - http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Feature.MiWi.Synchronization.Synchronization.DistributedSceneSupport