[Fiware-miwi] xml3d.js view to WebTundra & FiVES license question

[toni at playsign.net]

Yes I think LGPL is fine. I think it might be even simpler with a BSD-style (i.e. ‘do whatever’) license that Tundra, WebTundra (with Apache license), three.js and signals.js (with MIT) use, but really at least when limited to the xml3d.js view support in WebTundra, LGPL should be completely ok. We have happily used LGPL libs on the native side too, as Ogre used that earlier(*) and Qt uses it now (when Nokia bought it they changed it from dual-licensed GPL/commercial to LGPL which was great as it enabled anyone to use it freely and a lot of open source projects like IPython adopted it then).


About separate vs. combined repositories for server & client, I’ve been going a bit back&forth but again and I think finally settled on finding separate repositories for server & client good. At least when they are written for different platforms (e.g. native & web in case of Tundra & WebTundra) and hence don’t share code. They are really separate software projects then. 


One big reason is that using feature and other branches works sensibly then: for example a branch to refactor something in the client internals is then a branch with just the client code, doesn’t carry over the server code in vain. I actually don’t know if this is a real issue but have somehow felt that it’s clearer this way.


An obvious downside is that when changing something in the protocol or in core component definitions it’s not straightforward to keep the versions in sync when the changes to client & server sides are in separate repos. I suppose this is the reason why you’ve found it good for FiVES to work in a single repo .. and as the whole project is quite small still it has probably been good.


For Tundra WebSocket things, Lasse first also considered putting the JS client side also to the repo of the C++ server side .. in a client/ directory of the WebSocket server side module. I figured then a separate repo would be good for the js+browser based project and still find it the right call, based on how we’ve managed the branching and tagging etc. of the client then. Also because WebRocket is a separate client impl against the same server code I find this certainly the right setup in realXtend now.


If with KIARA we get a setup where the messages and component data structure definitions are shared by both server & client code then I think the situation changes. An option then would be an elaborate setup with multiple repos and git submodules: for example an own repo for the message / component definitions, touched when the protocol changes, and then the server & client implementations would have that protocol repo as a submodule. Git submodules seem great in theory for dependencies as we can control which exact version should be used where, getting the dep is nicely automated etc. In practice however I’m personally not at all comfortable with them yet. IPython is using them and had bugs in the beginning, IIRC due to bugs in the then new submodule functionality in git. I think they are doing ok now though. Blender switched to Git recently and also started using submodules and it seems problematic, someone said due to misuse of the feature. We are testing use of submodules in some of the WebTundra app repos, to get the WebTunda lib dependency, so are gaining more experience here.


Thanks for the info about the plans -- seems all sensible and good to me! BTW one thing I’m curious about with the C# server side is possibility to add web client support to OpenSimulator. It is what the Intel guys at Opensim Community Conference found interesting when I presented our web client plans back in September. All Opensim devs have always liked the reX ECA model and it might work ok to add support for such protocol for web clients there. Opensim remains somewhat technically problematic and marginal but also very interesting with the kind of large user base, innovate configurations with the Hypergrid and a nice demanding experienced VW user crowd used to creating both content and functionality by scripting themselves.


Cheers,

~Toni






From: torsten.spieldenner at dfki.de
Sent: ‎Monday‎, ‎March‎ ‎17‎, ‎2014 ‎11‎:‎44‎ ‎AM
To: FI-WARE, MiWi





Hi Toni,

sorry for not having replied earlier. I was spending Sunday with recovering from CeBIT, and am now about to catch up with the FI-Ware emails that arrived during the last days.

I'm happy to hear that you could made use of the FiVES code and that it worked to turn it to a WebTundra view. :)

This development is definitely interesting. With just a bit more of work on both client and server side (by introducing a slim KIARA layer in realXtend, for example), I can even see a use case where Synchronisation- and 3D-UI-Implementations are fully exchangeable, i.e. our FiVES client can connect to realXtend, and WebTundra GEi can connect to FiVES without any modifications.

Concerning licensing, I also think that LGPL should be no problem. If this is a suitable choice for you, we're going to discuss this with Sergiy and release the client code respectively.

I am also starting to think about separating the client code from the FiVES repo and put it in a repo of its own (with possibly a different, less restrictive license). We have to think about this anyway, as further plans about FiVES are involving more the client side rather than the server side. And for client development, a repository on its own means that one would not have to check out the whole server code as well when being interested only in the client frameworks.

Our plans concerning the Web client are currently to get rid of the few remaining hard coded hacks (e.g. fixed set of components to be initialised with new entities on client side, fixed set of plugins the client expects from the server to run, and some more minor things), and provide a Web Client skeleton without any plugin specific code (i.e. only communication and XML3D scene management) to build upon, in addition to the current client that implements more or less most of the features the server offers.

As Philipp already mentioned, I am moreover going to improve C# KIARA implementation. Background of this is also that in addition to XML3D / JavaScript WebClient, we would like to have basic client implementations for C# and, with the improvements introduced in C++ KIARA, also in C++, to derive distinct client implementations from. 

Best,
Torsten





Am 3/16/2014 7:08 PM, schrieb Philipp Slusallek:


Hi Toni, 

I think we have no issues going to LGPL if that is all that is needed. for now. Let me know and we will discuss this internally and get back to you. 

I think it would be great to merge the code bases and get to a common joint code that is much easier to maintain (particularly now in FI-Core). Also there are very interesting options to use this code to base Phase-3 project on, once we can commit them and make them more broadly available. 

Regarding further develoment, Torsten plan to soon start on a full KIARA implementation for FIVES (currently a lot is hardcoded), so we can have all the advantages of KIARA soon. 

We are also getting to the point where KIARA will become usable on the C/C++ side (for example, the latest benchmarks show that we can do roundtrip RPCs in less than 200 us on Gigabit Ethernet with it). This would allow the C/C++ Tundra to eventually switch to it as well. 

A number of other DFKI projects will also be porting to KIARA/FIVES in the upcoming weeks/months, so that we will get a lot more testing and extensions, where needed. It would be great to have you on board here as well. 

On a related note, we are working on large scene support right now using various techniques (this is needed for a nuber of automotive projects we are working on). We just got the first version of BLAST running which is a new highly efficient transfer format for XML3D (and also other formats). Jonne saw some demos at CeBIT, smoothly rendering a 5.7 Mtris city scene). We plan to publish this soon and submit it to Khronos as an alternative to their current glTF activities. 

At CeBIT we also showed first results of our new render pipeline implementation. Specifically it allowed to switch on Screen Space Ambient Occlusion (SSAO) as a post processing option. Other related effects should be realtively straight forward to implement. Let us know, if you are interested in adding your own extensions here. 


Best, 

    Philipp 
Am 16.03.2014 16:11, schrieb toni at playsign.net: 

As discussed often we are using three.js for rendering in WebTundra, 
mostly due to compatibility with existing realXtend requirements and 
applications for example on meshmoon.com. The requirement for 
declarative authoring is delivered by WebTundra’s SceneParser which can 
read an XML3D description and populate a reX EC scene from it. However 
thanks to applying the model-view-controller pattern the three.js 
dependency is limited to a view module in WebTundra: the networking and 
the internal core scene model, the entity-components which hold the 
data, don’t know anything about it. This was done mostly to allow 
running headless clients for example in node.js based simulation 
services. Erno is actually developing such bots now for the car & 
physics test/demo -- and as discussed this way the WebTundra codebase 
(without the view part) is an implementation of the Scene API epic too: 
it enables services to connect to a scene and modify it efficiently. 
However the MVC arch makes it also very straightforward to use xml3d.js 
for rendering instead, to get XFlow and Shade.js etc. support, and 
Philipp recommended in an email earlier that we’d implement that. 

I gave it a shot recently and am very happy to tell you that a simple 
proof-of-concept XML3DJSView was indeed quite straightforward to write 
and works enough now to initialize the view and show a test object in 
WebTundra. I used DFKI’s FiVES WebClient code as a reference for 
populating a scene from network data for xml3d.js to run. As also 
discussed already before the FiVES WebClient and WebTundra architectures 
are basically identical. It seemed that with some thought we might even 
share parts of the same code for FiVES WebClient and WebTundra’s 
XML3DJSView. Now I did it by copy-pasting and modifying appropriately. 

This brings up the question about FiVES licensing. It is currently GPL 
which we can not use in realXtend due to absolutely requiring support 
for also closed source proprietary applications. GPL requires any code 
that uses the library, in this case apps made on top of the FiVES 
WebClient framework, to provide the source code and AFAIK unlimited 
modification & redistribution rights for any user of the app. Even at 
Playsign where we use open source tech for basically everything and and 
happily participate in open source tool & platform development this is 
not possible for the applications: open sourcing our games and 
especially the graphics for them is out of the question (for one it 
would make it all too easy and legal to clone the games). I’m sure 
everyone knows how this is completely normal all around, both in games 
and other apps companies. I asked about the FiVES license previously at 
the F2F meet in Oulu and DFKI folks said they’d return to it but I 
suppose it has just fallen off the table due to other duties. 

So, is it possible to change the license? Do people find WebTundra with 
Tundra connectivity & XML3D.JS rendering interesting? What are the FiVES 
WebClient development plans, should we check if can reuse code in these 
two quite similar web clients? 

The little experimental code with the minimal required changes to get 
xml3d.js to run inside WebTundra are in a branch in Playsign’s fork of 
the repo. If the license is not changed I’ll never push this work to 
realXtend’s repo to keep the permissive licensing there absolutely 
clear. The current code is partly copy-pasted which AFAIK carries the 
license over. If the license is never changed but we need this 
functionality we’ll rewrite it somehow so that it is not a copy (some 
other person writes it without reading the FiVES code or so). 

Links for the curious tech folks who are not afraid of the GPL virus(*): 

  * 
    https://github.com/playsign/WebTundra/tree/xml3djs 
  * 
    https://github.com/playsign/WebTundra/blob/xml3djs/src/view/XML3DJSView.js
  * 
    https://github.com/playsign/WebTundra/compare/realXtend:dev...xml3djs 


I used the WebTundra XML3D-reading OpenCTM asset test, which is a copy 
of the original XML3D.JS OpenCTM demo (the ambulance) as the test -- so 
did not test by connecting to a Tundra server yet but populated the 
scene from a file instead (is faster to dev like that). The code should 
work for the networked case too though as the data source is almost 
completely invisible for the view module. Unfortunately I had trouble 
with xml3d.js openctm loading in my local dev setup (also for the normal 
xml3d.js ctm demo, which does work on-line) so had to hack the code just 
to show Suzanne for now. As the comparison against dev shows I just did 
all sorts of hardcoded mods for this now, there is no way to properly 
switch between the view implementations etc -- this was just a first 
stab to verify the idea and see what places would required changes etc. 

~Toni 

(*) previously when we worked with OpenSimulator and the Linden labs 
Second Life viewer code, which was GPL back then (is largely LGPL now), 
we were taught to be quite paranoid about GPL. The OpenSim contributor 
agreement stated that no one who had looked at the SL viewer code in 6 
months is allowed to commit code to OpenSim. This was due to advice by 
some mysterious lawyers (I suspect IBM, they did OpenSim dev at that 
time). I think it actually made sense: otherwise Linden labs could come 
and claim that OpenSim is derived work from SL (viewer) and that it 
should hence be GPLed as well (which again Opensim does not want due to 
supporting proprietary apps, like realXtend). So the solution within 
realXtend organization was to separate viewer and server development to 
different teams, in different companies at different locations .. Admino 
worked with Opensim and Ludocraft on the SL viewer based first realXtend 
viewer prototype. Now with our new codebases all that is luckily gone, 
and also for Opensim devs the SLViewer change to LGPL helped and IIRC 
they’ve dropped the contributor agreement so same people can work on 
server&clients there too. I’ve also encountered unrelated cases where 
professional programmers have steered away from even looking at GPL code 
for help / reference when implementing something to avoid problems (in a 
small completely not legalese database company, not related to 3d or VWs). 


_______________________________________________ 
Fiware-miwi mailing list 
Fiware-miwi at lists.fi-ware.eu 
https://lists.fi-ware.eu/listinfo/fiware-miwi 







_______________________________________________
Fiware-miwi mailing list
Fiware-miwi at lists.fi-ware.eu
https://lists.fi-ware.eu/listinfo/fiware-miwi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20140318/b128c8d2/attachment.html>