[Fiware-miwi] App architecture sketch

[Erno Kuusela]

Here's my understanding of how app architecture would differ between
current WebRocket vs our future "more declarative" system.  This is
biased in the implementation considerations toward using Tundra as the
server platform since that's what I know.

-----------------------------------------------------------------

*Current WebRocket client / Tundra Server*

1. Tundra server starts
- server loads scene description from txml,
- starts listening for client connections,
- server-side script entities that are defined to run on load
are started

2. client connects to server
- user navigates to a web page that loads WebRocket and specifies which
server address to connect
- client opens connection (Websocket)
- authentication happens
- server sends client scene contents (entities that have sync turned on)

3. Scene runs

- Client and server run and render according to what entities specify, scripts
work against the scene structure as reflected by the ECA, accessed using
the scripting API.
- Communication happens through entity-actions and
by changes to attribute values that are synced over the network.
(client->server syncs for attributes not implemented yet).

-----------------------------------------------------------------

* New more declarative ssytem - local scene case (no
server/syncronziation) *

1. Browser loads page with 3d scene
 - client is loaded from scripts specified by the web (html5) page
 - declarative ECA-based scene description is contained in the html5
 - document,
along the lines of (roughly)
  <scene>
    <entity id="1">
      <ec-script href="..">
      <ec-mesh>
        <!-- elements describing mesh -->
      </ec-mesh>
    </entity>
    <entity id="2">
      <!-- ... -->
    </entity>
  </scene>

 - Scripts get access to WebRocket style API for doing things in the
local scene

* New more declarative system, client-server case

 - several options:
   a) server loads the new declarative scene desc, and transmits it to
the clients via the sync protocol - then we'd need to reimplement more
smarts (such as the declarative scene format) also on the Tundra C++
side
   b) server works like in WebRocket case, using our existing TXML
scenes and transmitting the ECA structure over to the client.
Client can still manipulate them in the DOM but the client
side DOM only exists at runtime.
   c) Client loads the declarative scene description,
sees which of the entities are marked to use sync, and asks the server to set
up sync for them. Server only knows about the entities that clients
have told it about.

I've understood that the DFKI side sync server resembles c) the most.
For us it might be easily supported as well, since it's only the
local case and a small change to b) which is closest to 
current WebRocket.

"scene runs" phase is basically the same as WebRocket case. I
don't know if we want any changes to the entity-action system?

PS. I just ran into a nice sounding physics library for three.js:
http://chandlerprall.github.io/Physijs/