Hi,
I looked into the Shadow-DOM functionality of WebComponents a while ago.
I gives means to hide the canvas in the DOM (behind the XML3D element)
thus it feels even more native. However, in that days there were issues
in the Chrome Debugger that might have been fixed. I also didn't look
into the Polyfill implementation yet.
Using WebComponents together with XML3D would mean that xm3d.js would
have to consider the Shadow-DOM of components that are within the
<xml3d> element.
Best,
Kristian
Am 04.11.2013 08:02, schrieb Antti Kokko:
> Hello,
>
> I have been doing research and testing with Polymer and input devices.
> Regarding Polymer it really feels the way to go with the 2D-UI GE. I
> read somewhere that the AngularJS will be moving towards Shadow DOM as
> well and will include Polymer later on.
>
> With Polymer I have been doing a test implementation for chat app we
> have in WebRocket. Implementing the actual UI component with Polymer
> was pretty trivial and very nice to work with from a web designer
> point of view. As end result there is clear readable output including
> 2 html files and one css file. All functions have been encapsulated to
> the component itself. Therefore it becomes re-usable although in this
> case the component needs data binding and event hooking corresponding
> to the backend used. But in general when the backend is solid and
> decided implementing the web components will be nice work. Polymer
> already gives a huge set of components ready to use and work with. For
> this case I used polymer-collapse to slide up/down div elements I
> created. For this I needed only to import the corresponding
> polymer-collapse html file and hook it to my div element. Very easy
> and convenient. Right now I try to tackle the require js issues for
> WebRocket related to Polymer.
>
> For input devices I have been researching and testing touch JS libs
> and Gamepad API. For touch I tested couple of libraries and all of
> them worked well. As end result I chose jquery plugin and tested it
> against iPhone and iPad. Worked pretty well and I managed to get taps
> for 1-4 fingers, sliding and pinching to work. Shake and rotate didn´t
> work for some reason but I didn´t go deeper with that issue.
>
> For Gamepad I used Gamepad API
> [https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html]. Got it
> working well with Chrome. With Firefox it didn´t work even with
> Nightly build, don´t know the reason. Anyway the implementation is
> already tested against web rocket and Jonne did a nice test with the
> avatar app we have. Gamepad works like a charm. For tests we used XBOX
> 360 controller and Playstation controller. With Windows just plugging
> the device to USB port and pushing some button is everything needed.
> Both gamepads worked right away.
>
> The next thing with input is to test/research is Kinect.
>
> Thanks,
>
> - Antti
>
>
> On Sun, Nov 3, 2013 at 10:24 AM, Philipp Slusallek
> <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>> wrote:
>
> Hi,
>
> Sounds really good. I would suggest that we start defining the
> WebComponent components and their interfaces soon (of course,
> based on what you already use, but have a quick process to discuss
> if there could be improvements) and then go from there. In
> parallel we can check that XML3D works well with WebComponents and
> Polmer.
>
> I believe we have talked about that a bit already but I am not
> sure we have a specification for the WebComponents yet. Torsten,
> can you work with whoever feels responsible on the Finish side to
> come up with a common specification (somewhere on the private
> pages for now)?
>
> Sounds like we are all working in the same direction -- which is
> great! I can't wait to see the first avatars walking to Oulu city
> (or some other place) in any Web browser :-).
>
>
> Best,
>
> Philipp
>
> Am 03.11.2013 08:23, schrieb Toni Alatalo:
>
> Again a brief note about a single point:
>
> On 03 Nov 2013, at 09:12, Philipp Slusallek
> <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>
> <mailto:Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>>> wrote:
>
> Also there might be convenient components that would make
> 3D app
> programming with XML3D and WebComponents much easier. So
> for instance
> having the XML3D-based components automatically define the
> set of
> variable that need to be synchronized, registering them
> with the
> networking module (if available), and making sure this all
> gets done
> in the background would be excellent. Also providing an 3D
> avatar
> WebComponent with embedded animations and such would be
> ideal. It
> would be excellent if we could provide to Web developers a
> whole set
> of predefined and modular WebComponents that they could
> just use to
> create 3D worlds with behaviour.
>
>
> This is what realXtend has been doing for several years ---
> just outside
> the Web --- and plan is to continue doing the same on the Web
> as well :)
>
> That's how it works in the native Tundra, and plan for this
> fi-ware work
> to produce the web client (which also works standalone, like
> the native
> one does too) is to implement the same. That's also how it
> works in
> Chiru-WebClient and WebRocket, i.e. the pre-existing WebTundra's.
>
> ~Toni
>
> The one really big issue where I still see a lot of work
> on finding
> new solutions (not just implementation but real conceptual
> work) is
> dealing with the hugely varying set of input devices. One
> person has
> mouse and keyboard, the next has only a multi-touch
> surface, the next
> is using a Kinect, while yet another other is using a Wii
> Remote, etc.
> A single Web app will have to work with all of those
> situations
> simultaneously (on different devices, though). Letting Web
> application
> and their developers handle this in their apps will simply
> not work
> and be frustrating for developer and users.
>
> We have started to work on a concept for this but this has
> not gone
> very far yet. The coarse idea is that applications use virtual
> interaction elements to say what kind of input (metaphor)
> they are
> expected (e.g. selection of an object, moving an object).
> These are
> modules that can be configured and instantiated. They can
> also be
> nested within/on top each other (like non-visible dialog
> boxes)
> dynamically to have a hierarchical finite state machine of
> interactions.
>
> These interaction elements would consist of the
> interaction logic as
> well as (optionally) some interaction gadgets that
> visually represent
> the possible interactions (like handles to move and rotate
> an object).
> The key thing is that these interaction elements would be
> independent
> of the application, anyone can use them, and we could
> develop a whole
> library of them to cover the wide range of input metaphors
> that
> applications use (but applications can extend them with
> their own if
> needed).
>
> There are two extensions to this approach: (i) instead of
> having a
> single interaction element for each interaction metaphor
> we could have
> interfaces for them and develop entire user interface
> libraries that
> each have a different look and feel but still implement
> the same basic
> interaction metaphor. (ii) One could also design them such
> that users
> can change the mapping of the devices used for certain
> actions. Think
> of it as a reconfigurable gamer mouse, where the user can
> assign
> different action to certain buttons, gestures, or such. So
> a user can
> say, I will use the mouse to select objects but move them
> with the
> cursor keys (for a stupid simple example). These would be
> optional
> extensions for later, though.
>
> It would be great to work on those aspects together if
> this would be
> interesting to anyone of you. You probably have quite some
> experience
> in terms of good UI for 3D games/apps. Identifying,
> generalizing, and
> implementing them as a reusable set of components would a
> great step
> forward for 3D apps on the Web (or elsewhere). This would
> make great
> papers for conferences as well!
>
> If you want to go that way, we should probably set up a
> special
> session for discussing this in more detail.
>
>
> Best,
>
> Philipp
>
> Am 02.11.2013 17:35, schrieb Jonne Nauha:
>
> Yeah WebComponents are nice. I've already implemented
> quick tests for
> Tundras Entity and IComponent (common interface for
> all components,
> WebComponents has inheritance so it plays nicely into
> this) like 3-4
> months ago in our WebRocket web client. At that point
> I left it alone, I
> wanted to have my JS code that implements the
> component in a .js file
> not inside a .html polymer template. Currently I'm
> using requirejs for
> the whole repo as the amount of code and dependency
> tracking started to
> get out of hand, so I wanted a modular system where I
> can tell the
> system what each module needs as a dependency. This
> has been great but
> will make writing comp implementations in a
> WebComponent html template a
> bit trickier as it would expect everything to in
> global scope,
> requierejs effectively removes everything from global
> scope.
>
> I have also a simple DOM integration plugin for
> WebRocket. If you want
> to turn it on (configurable when you construct the
> client instance) it
> will mirror the whole scene/entity/component/attribute
> chain in to the
> DOM as my own
> <scene><entity><component><attribute/>...</component>...</entity>...</scene>
> nodes. This would be trivial to change to create XML3D
> nodes, but I cant
> test that out before everything on the asset side that
> has been
> discussed are complete. Because nothing would simply
> render if I wont
> provide the Ogre asset loaders for XML3D and it
> knowing how to used DDS
> textures. What I would prefer even more is to just
> pass you the geometry
> as data, because I have my own fully working AssetAPI
> to fetch the
> assets, and I have my own loaders for each asset type
> I support. I would
> kind of be duplicate work to re-implement then as
> XML3D loaders, when I
> alreayd have the ready typed gl arrays to give to you
> right now.
>
> For my current DOM "mirroring" plugin, if you
> manipulate the attributes
> in the DOM they wont sync up back to the in mem
> JavaScript attributes.
> So currently its read only. I haven't really had the
> need to implement
> the sync the other way as we are perfectly happy
> living in JS land and
> using the WebRocket SDK API to write our application
> logic. The
> declarative side is less important for Meshmoon
> WebRocket as the scenes
> are always coming from our Tundra based servers and
> not declared on the
> html page itself. For FIWARE the declarative and DOM
> side is more
> important and more in focus of course so I understand
> the direction of
> the talks and why XML3D is an valuable asset.
>
> Instantiating Scene, Entity and each of the Component
> implementation
> from a WebComponent template would solve this problem,
> as its designed
> to encapsulate the JS implementation and it has a
> great way to get
> callbacks when any attribute in the DOM node is
> manipulated. It can also
> expose DOM events and fire them, not to mention normal
> functions eg.
> $("<placeable>", entityNode).setPosition(10,20,30); so
> you dont have to
> use the raw DOM api to set string attributes by
> random. These functions
> would have type checking and not let you put carbage
> into the
> attributes. I believe the attribute changed handler
> can also effectively
> abort the change if you are trying to put a boolean to
> a Vector3
> attribute. This all is great and would just require us
> WebRocket devs to
> port our current EC implementations to WebComponent
> templates.
>
> But here is where I get confused. So you would be fine
> by us
> implementing Tundra components as WebComponent
> templates (as said this
> would be fairly trivial). How would XML3D then play
> into this situation?
> Would it now monitor our DOM elements instead of the
> ones you specify
> (afaik eg. <group> <mesh>)? Can you open up this a bit?
>
> *UI and WebComponents*
> *
> *
> WebComponents are also being looked at in our 2D-UI
> GE, but to be frank
> there is very little to do there. The system is
> incredibly simple to
> use. You include polymer.js to you page, add <link>
> tags to your Polymer
> style .html templates, then you just use the tags
> declared in them on
> the markup or you create the DOM nodes during runtime
> from JS with your
> preferred method. I'm having a bit of hard time
> figuring out what we
> should focus on in the 2D part for WebComponents. I
> mean they are there
> and you can use them, you don't need any kind of
> special APIs or
> supporting code from our side for them to work. Only
> thing I can think
> of is implementing some widgets and maybe 3D related
> templates for
> anyone when they use WebTundra.
>
> Best regards,
> Jonne Nauha
> Meshmoon developer at Adminotech Ltd.
> www.meshmoon.com <http://www.meshmoon.com>
> <http://www.meshmoon.com/><http://www.meshmoon.com
> <http://www.meshmoon.com/>>
>
>
>
> On Sat, Nov 2, 2013 at 1:21 PM, Philipp Slusallek
> <Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>
> <mailto:Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>><mailto:Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>>>
>
> wrote:
>
> Hi Toni, all,
>
> I have now looked at video on the main Polymer page
> (http://www.polymer-project.__org/
> <http://www.polymer-project.org/>), which is
> actually very nicely
> done. They make a very good point why its
> advantageous to put things
> in the DOM compared to pure JS applications (or
> even Angular, which
> already uses the DOM). They highlight that with
> WebComponents
> (Polymer is a polyfill implementation of them) this
> becomes now even
> easier and creates an object-oriented aspect for HTML.
>
> BTW, this aspect is exactly what we were aiming at
> when we suggested
> the use of WebComponents for the 2D-UI Epic in the
> objectives of the
> FI-WARE Open Call and I think we should push even
> more in this
> direction, similar to what I wrote in response to
> Jonne's email
> earlier.
>
> Regarding the mapping: We already have the mapping
> of 3D to the DOM
> (XML3D) as well as many modules that build on top
> of that mapping
> (Xflow with animation, image processing, and AR;
> portable materials,
> etc.). I see no reason why we should throw this out
> just because
> there is a slightly different way of doing it.
>
> I would even speculate that if we would try to
> offer similar
> functionality that at the end we would end up with
> something that
> would pretty much resemble XML3D, maybe with a
> slightly different
> syntax. There are usually not many way to do the
> same thing in a
> good way.
>
> What I would support 100%, however, is that we try
> to use
> Web*Components* to implement the *ECA components*
> (and possibly
> entities). Essentially for the same reasons
> explained in the video.
> That makes a lot of sense in the Web context and is
> fully compatible
> with the DOM and all the DOM-based frameworks that
> can then be used
> as well on this data.
>
> I have been saying for a long time that we have had
> libraries in
> C/C++. Just porting them to JS to run in the Web
> does not give us
> any advantages at all (likely only disadvantages
> like performance
> and an inferior language). Its only if we embrace
> the key elements
> of the Web -- and the runtime DOM arguably is the
> core of it all --
> that we can tap into all the benefits of the Web.
>
> And THE key advantage of the DOM is that you get
> *way more* than the
> sum of the pieces when putting things together.
> Instead, of making
> sure that one library can talk to all the others
> (which gets you
> into an N^2 complexity problem), each component
> only needs to work
> with the DOM (constant effort per component and you
> have to deal
> with one data structure anyway, so its essentially
> no overhead
> anyway). Then, you get the benefit from all other
> components
> *automatically and completely for free* (jquery and
> all the other
> tools "just work" also with XML3D, and we should be
> able to use
> XML3D within Polymer also).
>
> Note, that none of the Web technologies discussed here
> (WebComponents, Polymer, Angular, etc.) would work
> at all if they
> would not use the DOM at their core. Angular for
> example depends on
> the DOM and just allows a nicer binding of custom
> functionality
> (controller implemented in JS) to the DOM.
>
> This all applies exactly the same way also to 3D
> data -- at least
> logically. However, on the implementation side 3D
> is special because
> you have to take care of large data structures,
> typed arrays, and so
> on. This is what the main work in XML3D was all
> about. Why should
> someone invest all the effort to do it again for
> likely very similar
> results in the end?
>
> We can talk about using three.js as a renderer,
> though, but I would
> not touch the 3D DOM binding and data model that we
> already have in
> XML3D (unless someone comes with very good reasons
> to do so).
>
>
> Best,
>
> Philipp
>
>
> Am 02.11.2013 09:27, schrieb Toni Alatalo:
>
> On 02 Nov 2013, at 09:09, Philipp Slusallek
> <Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>
> <mailto:Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>><mailto:Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>>>
>
> wrote:
>
> Nice stuff. from my perspective there are
> two ways to look
> at this work: One is to provide high level
> UI elements on
> top of a three.js implementation and the
> other is the start
> of creating a declarative layer on top of
> the three.js
> renderer. This seems more along the first
> line but both
> should be similarly interesting to us.
>
>
> Indeed.
>
> It great to see that other people are
> coming up with similar
> ideas now. It would be good to get the
> message about our
> XML3D design and implementation to these
> people out there.
> That way we could improve what we already
> have instead of
> reinventing the wheel.
>
>
> That was my immediate first thought as well: it
> seemed like
> people have started to reinvent declarative 3d
> for the web from
> scratch. That's why I asked whether they knew
> about the existing
> work --- I understood that this Josh Galvin
> person (don't know him
> from before) who made the Spinner demo, did (am
> not sure).
>
> Thanks for the views and pointers, I'll keep an
> eye open for
> talks about this (actually just joined the
> #three.js irc channel
> on freenode yesterday, haven't been involved in
> their community
> before really --- Tapani from us has been
> hanging out there
> though). They seem to communicate most in the
> github issue
> tracker and pull requests (which I think is a
> great way).
>
> I also did not find an e-mail address to the
> polymer-threejs
> person, butkaosat.net <http://butkaosat.net>
> <http://kaosat.net/><http://kaosat.net
> <http://kaosat.net/>> is his personal site
>
> and apparently he made the original
> announcement of the
> declarative three.js thing in August in Google+
> so I figure e.g.
> replying there would be one way to comment:
> https://plus.google.com/__112899217323877236232/posts/__bUW1hrwHcAW
>
> <https://plus.google.com/112899217323877236232/posts/bUW1hrwHcAW>
> ..
> I can do that on Monday.
>
> BTW it seems that this guy is into hardware and
> cad and all
> sorts of things and declarative 3d xml is just
> a side thing for
> fun, perhaps related to his work on some cad
> thing --- is not like
> he'd be pursuing a career or a product or
> anything out of it.
>
> It seems like a straightforward mapping of the
> three.js API to
> xml elements: what I struggle to understand now
> is whether
> that's a good abstraction level and how does it
> correspond to
> xml3d's vocabulary.
>
> ~Toni
>
> It would be good if you can point people
> also to our papers
> from this year
>
> (http://graphics.cg.uni-__saarland.de/publications/
>
> <http://graphics.cg.uni-saarland.de/publications/>). They
> explain a lot of the background of why we
> have chose thing
> to work the way they work.
>
> More specifically:
> -- The "xml3d.js" paper explain a lot about
> the design of
> XML3D and its implementation
>
> (https://graphics.cg.uni-__saarland.de/2013/xml3djs-__architecture-of-a-polyfill-__implementation-of-xml3d/
>
> <https://graphics.cg.uni-saarland.de/2013/xml3djs-architecture-of-a-polyfill-implementation-of-xml3d/>).
> -- The "Declarative image processing" paper
> explains all the
> advantages one gets from exposing
> processing elements to the
> DOM instead of implementing them only in
> some JS libraries
>
> (https://graphics.cg.uni-__saarland.de/2013/declarative-__ar-and-image-processing-on-__the-web-with-xflow/
>
> <https://graphics.cg.uni-saarland.de/2013/declarative-ar-and-image-processing-on-the-web-with-xflow/>).
> -- And the 2012 paper on "XFlow" shows this
> usage for
> animation
>
> (https://graphics.cg.uni-__saarland.de/2012/xflow-__declarative-data-processing-__for-the-web/
>
> <https://graphics.cg.uni-saarland.de/2012/xflow-declarative-data-processing-for-the-web/>)
>
> Getting into a constructive discussion with
> some of these
> three.js people would be a good thing. I
> tried to find an
> email address for the polymer-threejs
> person but could not
> find any. Feel free to farward this email
> to him (and maybe
> others). I would love to get their feedback
> and engage in
> discussions.
>
>
> Best,
>
> Philipp
>
> Am 02.11.2013 00:38, schrieb Toni Alatalo:
>
> Apparently some three.js user/dev has
> gotten inspired by
> WebComponents &
> the Polymeer and written
> https://github.com/kaosat-dev/__polymer-threejs
>
> <https://github.com/kaosat-dev/polymer-threejs> :)
>
> Now another guy has continued with
> https://github.com/JoshGalvin/__three-polymer
>
> <https://github.com/JoshGalvin/three-polymer> --- there's
> a demo of custom
> element ('spinner'), similar to the
> Door case discussed
> here earlier.
>
> Had a brief chat with him, will return
> to this later but
> was fun to see
> the minimal webgl web component example
> there as that
> has been in our
> agenda.
>
> ~Toni
>
> 01:01 *<* galv*>*
> https://github.com/JoshGalvin/__three-polymer
>
> <https://github.com/JoshGalvin/three-polymer> added
> support for more basic geometry types
> 01:02 *<* galv*>* Going to do materials
> next
> 01:25 *<* *antont**>* galv: hee - are
> you aware of these
> btw?
> http://www.w3.org/community/__declarative3d/
>
> <http://www.w3.org/community/declarative3d/> , e.g.
> https://github.com/xml3d/__xml3d.js
> <https://github.com/xml3d/xml3d.js>
> 01:27 *<* galv*>* yeah, different level
> of abstraction
> 01:27 *<* *antont**>* perhaps
> 01:28 *<* galv*>* I expect people to
> wrap up their game
> objects
> 01:28 *<* galv*>* aka "spinner"
> 01:28 *<* galv*>* (index.html)
> 01:29 *<* *antont**>* we've been also
> planning to enable
> saying things
> like <door> if that's what you mean
> 01:30 *<* *antont**>* right, seems like
> the same idea
> 01:31 *<* *antont**>* very cool to see,
> gotta check the
> codes etc later
> .. but sleep now, laters
>
>
>
>
> _________________________________________________
> 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
> <mailto: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
>
> <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>
>
>
>
>
> --
>
>
> ------------------------------__------------------------------__-------------
> 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>
> <mailto:Fiware-miwi at lists.fi-ware.eu
> <mailto: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
>
>
>
>
> --
>
> -------------------------------------------------------------------------
> 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>
>
>
>
>
> --
>
> -------------------------------------------------------------------------
> 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
> https://lists.fi-ware.eu/listinfo/fiware-miwi
--
_______________________________________________________________________________
Kristian Sons
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
Agenten und Simulierte Realität
Campus, Geb. D 3 2, Raum 0.77
66123 Saarbrücken, Germany
Phone: +49 681 85775-3833
Phone: +49 681 302-3833
Fax: +49 681 85775--2235
kristian.sons at dfki.de
http://www.xml3d.org
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
Amtsgericht Kaiserslautern, HRB 2313
_______________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131104/0b2f5706/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy