Hi Juanjo, others - I promised to drop Juanjo a note about this in case we'll have a chance to talk at ECFI (am just arriving to Munich now). This is based on the discussions we had last week during the Madrid FI-CORE kickoff with Philipp, Tiina (Adminotech) and Sami (Cyberlightning): During the kickoff week, we discussed internally the consolidation and overall the situation with the alternative GEis from the MiWi chapter, now continued in the new WebUI chapter. Here are some notes from those talks to inform about possibilities and to base possible further talks now. Background and status ============== At the heart of WebUI are the interconnected client & server core packages, with the UI & Scene APIs and the Synchronization GE for connectivity. In our proposal for the 2nd open call, we presented a plan to realize that whole based on the pre-existing Tundra SDK from the realXtend open source organization. That is now the realXtend family of WebUI implementations: Synchronization GE with Tundra server & protocol (in C++), WebTundra client for 2D & 3D UI (Javascript), Virtual Characters, Interface Designer (scene editor) GEs etc. As a new feature for FIWARE goals specifically, WebTundra includes support for declarative authoring by implementing the XML3D spec for scene descriptions which can be embedded in the HTML DOM. Alternatively, there's the DFKI family: XML3D.js for 3DUI, FiVES as the synchronization server (in C#) and a FiVES web client that integrates XML3D.js similarily as WebTundra integrates three.js. FiVES design is a clone of realXtend Tundra in the sense that it applies the same Entity-Component model and is similarily modular being composed from plugins which implement the different components (such as avatars). I believe FiVES began (also) independently of FIWARE. A key to the puzzle is that, as DFKI participates also in the Middleware work, FiVES uses (/will use?) KIARA for the networking whereas Tundra & WebTundra use the traditional kNet library and the Tundra protocol with the codes that we had already before FIWARE. GIS, POI, Real-Virtual Interaction and other supporting services which are used via HTTP / REST APIs can be easily used from both families, either from web clients or from the server side in either case depending on the need. They are basically orthogonal to this discussion. Dealing with the present: document the alternatives ================================= A main worry with the situation is clarity for outside developers: we should have a clear message that state everywhere about how we envision FI WebUI apps to be developed. In practice it can be be useful to have options -- the different technologies here all have benefits and drawbacks, fitting different needs. One way to deal with the situation would be to simply present the alternatives and their suitabilities clearly. We do this already in the WebTundra manual when describe it's suitability and refer to xml3d.js and direct use of three.js for other needs. Something like this: - making a multiuser app? * does the Tundra server seem useful? Perhaps using Meshmoon hosting? go with Tundra & WebTundra, especially if three.js seems suitable * prefer the FiVES server? xml3d.js seems suitable? go with FiVES server & webclient (supposing they're mature enough) - making a singleuser app? or just a model / scene view? * something simple where just want to add a <mesh> tag to html doc, perhaps with a click handler, no complex js? xml3d.js can be nice * a complex app like a game, need a lot of special effects, perhaps physics, programming lots of custom functionality in js? three.js is the best choice, with the nice API, polished optimized implementations due to widespread commercial normal on-the-market use and tons of examples for everything This is not an absolutely perfect formulation but I think has truth in it as a basic rationale for choices -- a first draft to be improved of course. Organizing work on future development ========================= Besides presenting the current offering to application developers we need a clear plan for development activities. We are now planning to continue both tracks but with an eye for consolidation especially concerning integration with other FIWARE chapters, especially the KIARA Middleware. DFKI continues with the FiVES implementation to develop, test and proof KIARA's suitability for our use. We can then analyze possible switch of networking in Tundra & WebTundra to that base. At this point WebTundra and FiVES web client may become very similar and can possibly share code, for example the networking module and perhaps the abstract scene API which apps use to benefit from the automatic attribute synchronization. It may become even possible to merge WebTundra and FiVES web client altogether. They both have a model-view-controller architecture where the graphics rendering is interchangeable. There's already an experimental XML3D.js renderer using view to WebTundra so we could have a unified common client core codebase and still provide both xml3d.js and three.js renderers as alternatives. One way to merge would be to add a Kiara-using networking module to WebTundra, porting from the FiVES web client work. Regarding work on graphics, there is very little overlap with DFKI's graphics rendering research and development (for example the shade.js shader generator, BLAST asset format and the planned photorealistic rendering) -- simply because we don't do graphics rendering development for WebTundra on the realXtend side. Three.js is basically complete already for what it does and very actively maintained and further developed by others. We test and improve it as necessary but don't plan large efforts for new functionality. However, if DFKI's new technologies with the reference implementations in XML3D.js prove useful / necessary for realXtend applications, it may become topical to port e.g. shade.js or BLAST to work in three.js if we need to continue using that for other reasons. Possibilities with the renderer independent Scene API / Entity System =========================================== Notably much of realXtend application development is already renderer independent: instead of using a renderer scenegraph directly, we typically program using the entity system / scene api to benefit from the automated network synchronization. It is similar to the XML3D approach of manipulating the DOM (and we have a mapping between DOM and the EC / Scene). WebTundra has this API in the Scene module, and FiVES is getting a similar module as the implementation proceeds. On this high level, for simple applications, the underlying renderer is an implementation detail not visible when making simple application logic, such as adding / moving / removing objects in the 3d scene etc. A good strategy for further work may be to recognize this and emphasize the entity system / scene API as the core of the system and the entry point for developers. Deep down graphics programming is anyhow easily renderer specific but I think that's fine. An issue here is that there's no GE for this API. We have the specification linked from the Synchronization GE now. There is the Scene API EPIC, but it refers to the HTTP interface to the synchronization server and not this Javascript API that application developers in our cases typically use. I posted about this 'missing GE' issue to the MiWi list about a year ago, naming it the Entity System then. Perhaps this is the problem we should solve now? ~Toni
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy