[Fiware-webui] White-Paper

[Toni Alatalo]

Thought of this a bit -- at first yesterday thought it is a good idea
as seems kind of clear, but have been now reaching the conclusion that
it actually is not a good idea and am afraid it would be awfully
confusing actually.

Will need to get back to working on the demos soon enough (and take
kids to kindergarten first..) so am trying to be brief. Am sorry if
express things poorly or bluntly now but I hope you get the points
anyhow in a constructive fashion.

Comments in-lined:

On Wed, Nov 12, 2014 at 3:00 PM, Philipp Slusallek
<philipp.slusallek at dfki.de> wrote:
> I have looked at the white paper and here is what I would suggest we do:
> -- I suggest that we provide two subsections (i) one focused on
> interactive 3D in the browser using XML3D and (ii) one one virtual
> worlds using WebTundra. This allows all of us to highlight our strengths
> while not overlapping too much. Hope this is fine.

So to conclude in end the no, I don't think is a good idea but would
be just very confusing.

Interactive 3D in the browser, for any kinds of applications, is the
major use case for our 3D-UI offering as well. Also many of the other
GEs such as POI, GIS, the Interface Editor etc. are not tied to
Virtual Worlds which is really just more like one (even quite
marginal) application area.

One way would be to discuss VWs as a part of the Synchronization GE
but I think even that would be confusing as the Sync GE is again for
synching any data for any (usually 3d, but not necessarily even that)
applications and not limited to VWs.

> -- DFKI would then write the (i) using some examples for using XML3D
> probably also with AR as many developers ask for that now. Additionally
> we would be showing how to use the bundle we are defining right now
> (some recipes have been approved since our call this morning). Torsten
> (with Stefan) will write a subsection until Friday.

Luckily regarding these actual work items I agree, certainly makes
sense for everyone to document their things :)

One way to phrase the xml3d.js specific thing would be to call it
'DOM-integrated 3d' or something like that -- isn't that the
meaningful difference in the end? Compared to how three.js rendering
does not work via the DOM (currently at least -- basically because of
the performance difficulties there).

XML3D we do have implemented in WebTundra as well for the declarative
authoring (works now for the simple cases of adding 3d models to web
pages and configuring the view with xml3d tags as a part of the html
doc).

So I think the difference of xml3d.js and three.js in the end is quite
small when thinking of someone who just wants to add some 3d to a
website. They target the same audience and cover the same
functionality. Just the development style is a little different
(though not much as AFAIK also with xml3d.js you write the
functionality in Javascript -- and OTOH also three.js is declarative
authoring in the sense how you define the scene, and not how it's
drawn). Differences are more in how they are implemented and work as
projects -- with ups and downs on the both sides.

I think if we really want to serve the developer & business
communities with this description of the techs we should create a very
specific and as exact clarifications here as we can.

BTW, perhaps you know this already, but for me this was new: "3D
graphics on the web: A survey" published in Computers & Graphics
Volume 41, June 2014, Pages 43–61 --
http://www.sciencedirect.com/science/article/pii/S0097849314000260

I think that does a fair job describing at least a part of the
situation (and doesn't have an awful lot of errors, I spotted only a
couple small ones), discusses both xml3d.js and three.js specifically.
Was fun to see they also had the same conclusion we've had (thanks to
Philipp's note back in Winterthur) how three.js is declarative too :)
.. perhaps we could refer to that for further info?

Regarding how I understand the differences of xml3d.js and three.js now:

xml3d.js dev is more controlled, there's a professional team working
on it, AFAIK it doesn't break bw compat too easily (perhaps :) etc.
And there's a spec and publications. It is not used much on the Web
yet but already has some solid business cases and potential for more
as there are great techs like Blast with the pop-buffers impl there.

Three.js is chaotic, only the lead dev is kind indirectly paid to work
on it (was hired by Google long ago and I think can maintain also
three.js besides the other work that does for webgl apps at Google,
using also other libs (his own alternative ones) and also plain webgl
I think)). But it's wildly popular on the Web, some even declare as a
de-facto standard (I don't and wouldn't), lots of hobbyists but also
commercial cases from ad agencies etc. but also solid products by
serious companies: Microsoft's Photosynth2 and Sketchup's (separated
from Google now again) web viewer use it. The API, the data formats,
everything lives and breaks in the informal development .. which does
progress greatly all the time. Biggest upsides are that due to the
very active development and use it is both proven and most
battle-tested for commercial applications on all platforms, and I
think most of all that it has all the imaginable (at least basic)
features and examples .. that you can copy-and paste to your app and
quickly make succesful business.

The chaos there is I think where we can and should help: we can serve
as a buffer kind of stabilising three.js. The version that we offer as
the official GE is tested and documented -- by us -- to work. Complete
with the asset pipelines. I really think it is one of the best uses we
can have with this EU money that help people there .. so we try to
help people on the #three.js irc channel etc. as much as we can. We're
basically the only ones in the world paid to do it after all.

> -- I suggest that the Oulu partners write subsection (ii). Again it
> probably makes sense to refer to the bundles you are defining right now.
> This allows users to simply create a a VM with this stuff, get a first
> good experience, and then allow them to play around with it.

I don't know from where the focus on the bundles comes here.

Sure it makes sense to describe those too, but honestly I think for
many businesses the GEs are more easily useful as standalone GEs.

For example when speaking with companies who have considering applying
for the accelerator funding I've mentioned the POI (and CB) GEs as
examples that some business could integrate to their product. In cases
where they have had (for example in a mobile phone app) some location
specific information (like sports data tracking) where the POI GE
would work. Sometimes I haven't even mentioned the 3d stuff exists
because it has been clear that it's irrelevant for their business.

Also in the cases where the startups have already existing code, or at
least already clear ideas how to create their product, again the right
granularity seems to be individual GEs. Some can use the GIS backend
from their own server backend and then whatever they've already
decided for UI.

In general I think many devs are (rightfully, I think) afraid of
complex things with many parts. But want small simple libraries that
do one well defined thing well (the old unix philosophy, though I
doubt those new devs have even heard of that :)

> -- I like the intro section with the architecture overview but we
> probably need to change this a bit once we have the two subsections.
> However, we should keep the intro section generic and mainly providing
> an overview of the general architecture and the big picture what the GEs
> are doing and how they fit together.

So based on the above I'm afraid too much emphasis on this can scare
people away.

> Regarding the question from Tiina this morning: I do not think that we
> need to include each and every of our GEs in the document. It is meant
> to be a starting point for people looking at FIWARE. So just
> highlighting the GEs in the examples should be fine.
>
> We may however, add a brief list of all our GEs at the end of the intro
> with links to their pages in the Wiki.

And again based on the above I'd indeed include such a list and
emphasize that they can be used individually.

In general for all of FIWARE I'd downplay the notion of an
all-encompassing platform that tries to solve everything and put
everything in the same model. I think it's often a big mistake to try
to make and provide a Framework. Instead you wanna give pieces that
people can cherry-pick and use in the framework that they already have
or build.

Sometimes I've described it as a library of open source projects --
and the catalogue facilitates that greatly already.

Contrastingly yours, but hopefully in a constructive way! :)

And is great you pointed out the 'interactive 3d on a web page' use
case as I agree that it is a nice basic use case, perhaps the most
relevant for Playsign as well, as not all 3d things have to do with
POIs or GIS but can be just for example interior design or just
decoration on a web page etc.

I'm sorry that am just ranting and not actually working to improve the
doc now but at least got to reply to the fair suggestion -- thanks for
posting it, hopefully this step also helps us forward.

>         Philipp

~Toni

> Trippstadter Strasse 122, D-67663 Kaiserslautern
>
> Geschäftsführung:
>   Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>   Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
>   Prof. Dr. h.c. Hans A. Aukes
>
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973, Steuernummer:  19/673/0060/3
> ---------------------------------------------------------------------------
>
> _______________________________________________
> Fiware-webui mailing list
> Fiware-webui at lists.fi-ware.org
> https://lists.fi-ware.org/listinfo/fiware-webui
>