On 09 Nov 2013, at 09:02, Philipp Slusallek <Philipp.Slusallek at dfki.de> wrote:
> I think we would need very strong reasons not to use the DOM as the basis for the Interface Designer as this project is based on the declarative 3D approach.
I think that is not the question here, actually. Depends on what you mean with ‘as the basis’ there. I mean:
It is established that the scenes are declarative — that has been the practise in both background projects (realXtend & xml3d) for years. The Interface Designer / Scene editor works on the scene declarations. That’s how the editor in native Tundra works as well (Scene Structure & EC editors).
It is also established that the DOM is used. It is the basis in any case in that sense, at least from a user POV the editor is a way to work with the DOM: it shows the scene data from your XML, changes made with the editor appear in the browser debugger DOM view (this works even in the current impl on WebRocket if you enable Jonne’s experimental DOM integration plugin there), and you can save the doc as XML.
The question is: what is a good API — in memory — for the editor to work with the declarations?
Would the DOM suffice for it or do we need something else to support it to get the required attribute metadata?
> It would also be good to be able to handle XML3D data directly without the WebComponent layer on top of them. We are building Generic Enablers and not all application will need or want to use the WebComponents as we are defining them.
In my understanding the idea is that XML3D data == reX EC data so that is implied.
I was just thinking that *if* DOM itself does not suffice, WC definitions might be a possible supporting system from where to get the attribute type definitions for example.
But thanks for rising the point: it would be interesting to know also whether the XML3D.js internal structures would have similar supporting features. With those JS datatypes we can probably know nicely whether some attribute is a transform, for example. Perhaps somehow with the DOM access too? Another example is whether some attribute is an integer or decimal (float) number, and ideally what is the valid value range for it.
> From my point of view, the mapping of WebComponents or XML3D elements to the ECA model (likely via KIARA) should happen independently of the editor and be defined either generically (if using XML3D) or by the WebComponents themselves. This mapping can be nicely hidden within them and only they know what data needs to be sent to keep the component in sync.
I’m not actually sure whether we need the mapping at all if we can just agree on what e.g. attribute names to use :) For example if reX decides it’s fine to switch the name of ‘meshRef’ attribute of the Mesh component to ‘src’ like it is in XML3D. The doc of current API in WebRocket: http://doc.meshmoon.com/doxygen/webrocket/classes/tundra.EC_Mesh.html#property_meshRef%20(attribute) . (that does bring the question how to have material & skeleton references etc. but that’s another discussion, I’ll actually need to check how those are in XML3D).
The mapping would then be needed only for (legacy) TXML loading which is fine — but not related to how the internals of especially the web client work.
In my understanding the network synchronisation would not need it as it’d simply be just implemented so that a Mesh component is added as a .. mesh component, i.e. (also a) DOM element — either via a Scene API or directly to the DOM.
This understanding can very well be wrong, though :) .. to be tested more still.
> BTW, I will be arriving in Oulu at 17:05h on Sunday (I assume that Torsten has the same flight). Maybe, we could have dinner together tomorrow? (If anything has been planned already, please send me a quick reminder as I am buried in 300 email from the last few days at ICT 2013 in Vilnius and I am only slowly catching up :-( ).
We discussed this in the weekly and we agreed to meet Sunday evening already, Christof and IIRC Torsten at least were interested. We talked of just going for a beer but dinner would probably be good. We were thinking of 7pm or so? We put phonenums to the doc but mine is +358 40 7198759 and I can come to your hotel(s?) etc. and we can go somewhere — the town is small and easy. I don’t know who from Oulu thought of coming but everyone is certainly welcome (just don’t confuse this with the ‘official’ dinner on Monday).
> Best and see you all in Oulu,
Welcome :) .. Very beautiful city and area much of the year, most ugly time of the year for a possibly extreme experience.. (can be dark, no snow yet).
> Philipp
~Toni
>
> Am 08.11.2013 07:47, schrieb Toni Alatalo:
>> A specific question for the UI Designer / scene builder team at Admino:
>>
>> Your current implementation is against reX entity system as JS objects
>> (the WebRocket scene implementation) — diagram b) in the previous post.
>>
>> Would the editor be well implementable directly against the DOM? — the
>> option in diagram a).
>>
>> I think a key point is attribute metadata, for example type and valid
>> value range, and perhaps handling attribute types such as transform and
>> color with special editing widgets (transform gizmo, color palette
>> selector) etc. Do you think all that could work somehow nicely when
>> using the DOM directly, perhaps by having the type information in
>> WebComponent definitions? (you are the experts on this too thanks to the
>> 2D UI work)
>>
>> Or does the editor in practice require the kind of entity system with
>> attribute objects which you are using currently?
>>
>> We can discuss this at the office or in the Monday meet but I figured to
>> post the question here anyhow as the discussion has been here otherwise
>> and there’s no comments yet. I think UIDesigner as a user of the entity
>> system is good to analyse now as it’s already fairly complete — other
>> users such as synchronisation are not as far yet.
>>
>> Cheers,
>> ~Toni
>>
>> On 06 Nov 2013, at 13:06, Toni Alatalo <toni at playsign.net
>> <mailto:toni at playsign.net>> wrote:
>>
>>> Hi returning to this as it’s still unclear for me and we need to
>>> implement this for integrating the client side of the synchronisation
>>> (that Lasse is working on) & the rest of the client:
>>>
>>> On 03 Nov 2013, at 11:19, Philipp Slusallek <Philipp.Slusallek at dfki.de
>>> <mailto:Philipp.Slusallek at dfki.de>> wrote:
>>>> No, we would still have to maintain the scene representation in the
>>>> DOM. However, we can use the specialized access functions (not the
>>>> string-valued attributes) to access the functionality of a (XML3D)
>>>> DOM node much more efficiently than having to parse strings. Torstens
>>>> example with the rotation is a good example of such a specialized
>>>> interface of an (XML3D) DOM node.
>>>
>>> Yes I think everyone agrees that the representation is good to have
>>> there (also) but the question is indeed about efficient ways of
>>> modification.
>>>
>>> Question: are those specialised access functions the same thing to
>>> what Kristian refers to in this quote from September 2nd (Re:
>>> [Fiware-miwi] massive DOM manipulation benchmark)? I think not as you
>>> & Torsten talk about access to DOM elements whereas Kristian talks
>>> about something not in the DOM, or?
>>>
>>> "The DOM is meant as in interface to the user. That's how we designed
>>> XML3D. All medium-range modification (a few hundereds per frame) are
>>> okay. One must not forget that users will use jQuery etc, which can --
>>> used the wrong way -- slow down the whole application (not only for 3D
>>> content). For all other operations, we have concept like Xflow, where
>>> the calculation is hidden behind the DOM interface. Also the rendering
>>> is also hidden behind the DOM structure. We even have our own memory
>>> management to get a better JS performance.”
>>>
>>> I’m referring to the parts about ‘hidden behind the DOM’, used by
>>> XFlow and rendering.
>>>
>>> Do those use and modify some non-DOM data structures which xml3d.js
>>> has for the scene internally?
>>>
>>> We are fine with reading existing docs or even just source code for
>>> these things, you don’t have to explain everything in the emails here,
>>> but yes/no answers & pointers to more information (e.g. to relevant
>>> code files on github) would be very helpful.
>>>
>>> So now in particular I’m figuring out whether that kind of ‘hidden’ /
>>> non-DOM interface would be the suitable one for network
>>> synchronisation to use.
>>>
>>> I know that changes coming over the net are not usually *that* much,
>>> typically within the max hundreds (and usually much less) for which
>>> Kristian states that going via DOM manipulation is fine, but there can
>>> be quite large bursts (e.g. at login to create the whole scene, or
>>> when some logic changes a big part of it). And there are many
>>> consumers for the cpu time available in the browser main thread so is
>>> perhaps good to avoid wasting even a little of it in continuous
>>> movement update handling etc. And in any case it’s good for us to know
>>> and understand how the DOM interfacing works — even if it turns out
>>> the efficient alternative is not necessary for networking.
>>>
>>> In the current WebTundras we have the same structure as in the native
>>> Tundra, i.e. there are normal software objects (non-DOM) for the
>>> entity-system level entities & components, and the 3d visual ones of
>>> those are proxies for the concrete implementations of scene nodes and
>>> meshes etc. in Three.js / Ogre respectively. And the experimental
>>> DOM-integration that Jonne made in WebRocket then mirrors that JS EC
>>> structure to the DOM periodically.
>>>
>>> These two old client architecture sketch diagrams illustrate the options:
>>>
>>> a) net sync updates DOM, rendering gets updates via DOM:
>>> https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg
>>>
>>> b) net sync updates JS objects, optimised batched sync updates DOM:
>>> https://rawgithub.com/realXtend/doc/master/dom/rexdom-dom_as_ui.svg
>>>
>>> Until now I thought that we settled on b) back then in early September
>>> as I understood that it’s what you also do & recommend (and that’s
>>> what WebTundras have been doing so far).
>>>
>>>> Philipp
>>>
>>> ~Toni
>>>
>>>> Am 31.10.2013 10:42, schrieb Toni Alatalo:
>>>>> On 31 Oct 2013, at 11:23, Torsten Spieldenner
>>>>> <torsten.spieldenner at dfki.de
>>>>> <mailto:torsten.spieldenner at dfki.de><mailto:torsten.spieldenner at dfki.de>>
>>>>> wrote:
>>>>>> On top the capabilities of the DOM API and additional powers of
>>>>>> sophisticated JavaScript-libraries, XML3D introduces an API extension
>>>>>> by its own to provide a convenient way to access the DOM elements as
>>>>>> XML3D-Elements, for example retrieving translation as XML3DVec3 or
>>>>>> Rotation as XML3DRotation (for example, to retrieve the rotation part
>>>>>> of an XML3D transformation, you can do this by using jQuery to query
>>>>>> the transformation node from the DOM, and access the rotation there
>>>>>> then: var r = $("#my_transformation").rotation).
>>>>>
>>>>> What confuses me here is:
>>>>>
>>>>> earlier it was concluded that ‘the DOM is the UI’, I understood meaning
>>>>> how it works for people to
>>>>>
>>>>> a) author apps — e.g. declare that oulu3d scene and reX avatar & chat
>>>>> apps are used in my html, along this nice christmas themed thing I just
>>>>> created (like txml is used in reX now)
>>>>>
>>>>> b) see and manipulate the state in the browser view-source & developer /
>>>>> debugger DOM views (like the Scene Structure editor in Tundra)
>>>>>
>>>>> c) (something else that escaped me now)
>>>>>
>>>>> Anyhow the point being that intensive manipulations such as creating and
>>>>> manipulating tens of thousands of entities are not done via it. This was
>>>>> the response to our initial ‘massive dom manipulation’ perf test.
>>>>> Manipulating transformation is a typical example where that happens — I
>>>>> know that declarative ways can often be a good way to deal with e.g.
>>>>> moving objects, like the PhysicsMotor in Tundra and I think what XFlow
>>>>> (targets to) cover(s) too, but not always nor for everything so I think
>>>>> the point is still valid.
>>>>>
>>>>> So do you use a different API for heavy tasks and the DOM for other
>>>>> things or how does it go?
>>>>>
>>>>> ~Toni
>>>>>
>>>>>>> If we think that XML3D (or the DOM and XML3D acts on those
>>>>>>> manipulations)
>>>>>>> is already this perfect API I'm not sure what we are even trying to
>>>>>>> accomplish here? If we are not building a nice to use 3D SDK whats the
>>>>>>> target here?
>>>>>> I totally agree that we still need to build this easily programmable
>>>>>> 3D SDK. But XML3D makes it very simple to maintain the 3D scene in the
>>>>>> DOM according to the scene state of the application.
>>>>>> You may want to have a look at our example web client for our FiVES
>>>>>> server (https://github.com/rryk/FiVES). Although I admit that the code
>>>>>> needs some refactoring, the example of how entities are created shows
>>>>>> this nicely : As soon as you create a new Entity object, the DOM
>>>>>> representation of its scenegraph and its transformations are created
>>>>>> automatically and maintained as View of the entity model. As
>>>>>> developer, you only need to operate on the client application's API.
>>>>>> This could be an example, of how an SDK could operate on the XML3D
>>>>>> representation of the scene.
>>>>>>
>>>>>>
>>>>>> ~ Torsten
>>>>>>
>>>>>>> On Wed, Oct 30, 2013 at 11:35 PM, Philipp Slusallek <
>>>>>>> Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>> wrote:
>>>>>>>
>>>>>>>> Hi Jonne, all,
>>>>>>>>
>>>>>>>> I am not sure that applying the Tudra API in the Web context is
>>>>>>>> really the
>>>>>>>> right approach. One of the key differences is that we already have a
>>>>>>>> central "scene" data structure and it already handles rendering
>>>>>>>> and input
>>>>>>>> (DOM events), and other aspects. Also an API oriented approach
>>>>>>>> may not be
>>>>>>>> the best option in this declarative context either (even though I
>>>>>>>> understands that it feels more natural when coming from C++, I
>>>>>>>> had the same
>>>>>>>> issues).
>>>>>>>>
>>>>>>>> So let me be a bit more specific:
>>>>>>>>
>>>>>>>> -- Network: So, yes we need a network module. It's not something that
>>>>>>>> "lives" in the DOM but rather watches it and sends updates to the
>>>>>>>> server to
>>>>>>>> achieve sync.
>>>>>>>>
>>>>>>>> -- Renderer: Why do we need an object here. Its part of the DOM
>>>>>>>> model. The
>>>>>>>> only aspect is that we may want to set renderer-specific
>>>>>>>> parameters. We
>>>>>>>> currently do so through the <xml3d> DOM element, which seems like
>>>>>>>> a good
>>>>>>>> approach. The issues to be discussed here is what would be the
>>>>>>>> advantages
>>>>>>>> of a three.js based renderer and implement it of really needed.
>>>>>>>>
>>>>>>>> -- Scene: This can be done in the DOM nicely and with
>>>>>>>> WebComponents its
>>>>>>>> even more elegant. The scene objects are simple part of the same
>>>>>>>> DOM but
>>>>>>>> only some of them get rendered. I am not even sure that we need
>>>>>>>> here in
>>>>>>>> addition to the DOM and suitable mappings for the components.
>>>>>>>>
>>>>>>>> -- Asset: As you say this is already built-into the XML3D DOM. I
>>>>>>>> see it a
>>>>>>>> bit like the network system in that it watches missing resources
>>>>>>>> in the DOM
>>>>>>>> (plus attributes on priotity and such?) and implements a sort of
>>>>>>>> scheduler
>>>>>>>> excutes requests in some priority order. A version that only
>>>>>>>> loads missing
>>>>>>>> resources if is already available, one that goes even further and
>>>>>>>> deletes
>>>>>>>> unneeded resources could probably be ported from your resource
>>>>>>>> manager.
>>>>>>>>
>>>>>>>> -- UI: That is why we are building on top of HTML, which is a
>>>>>>>> pretty good
>>>>>>>> UI layer in many requests. We have the 2D-UI GE to look into missing
>>>>>>>> functionality
>>>>>>>>
>>>>>>>> -- Input: This also is already built in as the DOM as events
>>>>>>>> traverse the
>>>>>>>> DOM. It is widely used in all WEB based UIs and has proven quite
>>>>>>>> useful
>>>>>>>> there. Here we can nicely combine it with the 3D scene model
>>>>>>>> where events
>>>>>>>> are not only delivered to the 3D graphics elements but can be
>>>>>>>> handled by
>>>>>>>> the elements or components even before that.
>>>>>>>>
>>>>>>>> But maybe I am missunderstanding you here?
>>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Philipp
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 30.10.2013 14:31, schrieb Jonne Nauha:
>>>>>>>>
>>>>>>>>> var client =
>>>>>>>>> {
>>>>>>>>> network : Object, // Network sync, connect, disconnect etc.
>>>>>>>>> functionality.
>>>>>>>>> // Implemented by scene sync GE (Ludocraft).
>>>>>>>>>
>>>>>>>>> renderer : Object, // API for 3D rendering engine access,
>>>>>>>>> creating
>>>>>>>>> scene nodes, updating their transforms, raycasting etc.
>>>>>>>>> // Implemented by 3D UI (Playsign).
>>>>>>>>>
>>>>>>>>> scene : Object, // API for accessing the
>>>>>>>>> Entity-Component-Attribute model.
>>>>>>>>> // Implemented by ???
>>>>>>>>>
>>>>>>>>> asset : Object, // Not strictly necessary for xml3d as
>>>>>>>>> it does
>>>>>>>>> asset requests for us, but for three.js this is pretty much needed.
>>>>>>>>> // Implemented by ???
>>>>>>>>>
>>>>>>>>> ui : Object, // API to add/remove widgets correctly
>>>>>>>>> on top
>>>>>>>>> of the 3D rendering canvas element, window resize events etc.
>>>>>>>>> // Implemented by 2D/Input GE (Adminotech).
>>>>>>>>>
>>>>>>>>> input : Object // API to hook to input events occurring
>>>>>>>>> on top
>>>>>>>>> of the 3D scene.
>>>>>>>>> // Implemented by 2D/Input GE (Adminotech).
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Jonne Nauha
>>>>>>>>> Meshmoon developer at Adminotech Ltd.
>>>>>>>>> www.meshmoon.com
>>>>>>>>> <http://www.meshmoon.com/> <http://www.meshmoon.com
>>>>>>>>> <http://www.meshmoon.com/>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Oct 30, 2013 at 9:51 AM, Toni Alatalo <toni at playsign.net
>>>>>>>>> <mailto:toni at playsign.net>
>>>>>>>>> <mailto:toni at playsign.net>> wrote:
>>>>>>>>>
>>>>>>>>> Hi again,
>>>>>>>>> new angle here: calling devs *outside* the 3D UI GE: POIs,
>>>>>>>>> real-virtual interaction, interface designer, virtual
>>>>>>>>> characters, 3d
>>>>>>>>> capture, synchronization etc.
>>>>>>>>> I think we need to proceed rapidly with integration now and
>>>>>>>>> propose
>>>>>>>>> that one next step towards that is to analyze the interfaces
>>>>>>>>> between
>>>>>>>>> 3D UI and other GEs. This is because it seems to be a
>>>>>>>>> central part
>>>>>>>>> with which many others interface: that is evident in the old
>>>>>>>>> 'arch.png' where we analyzed GE/Epic interdependencies: is
>>>>>>>>> embedded
>>>>>>>>> in section 2 in the Winterthur arch discussion notes which
>>>>>>>>> hopefully
>>>>>>>>> works for everyone to see,
>>>>>>>>> https://docs.google.com/**document/d/**1Sr4rg44yGxK8jj6yBsayCwfitZTq5
>>>>>>>>> **Cdyyb_xC25vhhE/edit<https://docs.google.com/document/d/1Sr4rg44yGxK8jj6yBsayCwfitZTq5Cdyyb_xC25vhhE/edit>
>>>>>>>>> I propose a process where we go through the usage patterns
>>>>>>>>> case by
>>>>>>>>> case. For example so that me & Erno visit the other devs to
>>>>>>>>> discuss
>>>>>>>>> it. I think a good goal for those sessions is to define and
>>>>>>>>> plan the
>>>>>>>>> implementation of first tests / minimal use cases where the
>>>>>>>>> other
>>>>>>>>> GEs are used together with 3D UI to show something. I'd like
>>>>>>>>> this
>>>>>>>>> first pass to happen quickly so that within 2 weeks from the
>>>>>>>>> planning the first case is implemented. So if we get to have the
>>>>>>>>> sessions within 2 weeks from now, in a month we'd have demos
>>>>>>>>> with
>>>>>>>>> all parts.
>>>>>>>>> Let's organize this so that those who think this applies to
>>>>>>>>> their
>>>>>>>>> work contact me with private email (to not spam the list),
>>>>>>>>> we meet
>>>>>>>>> and collect the notes to the wiki and inform this list about
>>>>>>>>> that.
>>>>>>>>> One question of particular interest to me here is: can the
>>>>>>>>> users of
>>>>>>>>> 3D UI do what they need well on the entity system level (for
>>>>>>>>> example
>>>>>>>>> just add and configure mesh components), or do they need deeper
>>>>>>>>> access to the 3d scene and rendering (spatial queries, somehow
>>>>>>>>> affect the rendering pipeline etc). With Tundra we have the
>>>>>>>>> Scene API and the (Ogre)World API(s) to support the latter,
>>>>>>>>> and also
>>>>>>>>> access to the renderer directly. OTOH the entity system level is
>>>>>>>>> renderer independent.
>>>>>>>>> Synchronization is a special case which requires good two-way
>>>>>>>>> integration with 3D UI. Luckily it's something that we and
>>>>>>>>> especially Lasse himself knows already from how it works in
>>>>>>>>> Tundra
>>>>>>>>> (and in WebTundras). Definitely to be discussed and planned
>>>>>>>>> now too
>>>>>>>>> of course.
>>>>>>>>> So please if you agree that this is a good process do raise
>>>>>>>>> hands
>>>>>>>>> and let's start working on it! We can discuss this in the
>>>>>>>>> weekly too
>>>>>>>>> if needed.
>>>>>>>>> Cheers,
>>>>>>>>> ~Toni
>>>>>>>>>
>>>>>>>>> ______________________________**_________________
>>>>>>>>> Fiware-miwi mailing list
>>>>>>>>> Fiware-miwi at lists.fi-ware.eu
>>>>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>>>>>> <mailto:Fiware-miwi at lists.fi-**ware.eu
>>>>>>>>> <http://ware.eu/><Fiware-miwi at lists.fi-ware.eu
>>>>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu>>
>>>>>>>>> https://lists.fi-ware.eu/**listinfo/fiware-miwi<https://lists.fi-ware.eu/listinfo/fiware-miwi>
>>>>>>>>> <https://lists.fi-ware.eu/**listinfo/fiware-miwi%3Chttps://lists.fi-ware.eu/listinfo/fiware-miwi%3E>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ______________________________**_________________
>>>>>>>>> Fiware-miwi mailing list
>>>>>>>>> Fiware-miwi at lists.fi-ware.eu <mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>>>>>> https://lists.fi-ware.eu/**listinfo/fiware-miwi<https://lists.fi-ware.eu/listinfo/fiware-miwi>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> ------------------------------**------------------------------**
>>>>>>>> -------------
>>>>>>>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>>>>>>>> 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-miwi mailing list
>>>>>>> Fiware-miwi at lists.fi-ware.eu <mailto: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
>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu><mailto: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 <mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>> https://lists.fi-ware.eu/listinfo/fiware-miwi
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> -------------------------------------------------------------------------
>>>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>>>> 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
>>>> ---------------------------------------------------------------------------
>>>> <slusallek.vcf>
>>>
>>
>>
>>
>> _______________________________________________
>> Fiware-miwi mailing list
>> Fiware-miwi at lists.fi-ware.eu
>> https://lists.fi-ware.eu/listinfo/fiware-miwi
>>
>
>
> --
>
> -------------------------------------------------------------------------
> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
> 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
> ---------------------------------------------------------------------------
> <slusallek.vcf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131109/39a8516c/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy