Hi - sorry about the old link to the arch diag but the current one is also the same: client core is a thing there, and it describes well what WebTundra implements. I agree that it is useful to have the GEs as separate ones too but was focusing on the case where the client core is provided as a single with a unified API. One place where I gave a shot at describing these different use cases was for the ex- White Paper which became the developer guide: https://www.fiware.org/devguides/providing-an-advanced-user-experience-ux/3d-ui-interactive-3d-graphics-and-augmented-reality-in-any-web-browser/ ~Toni On Wed, Sep 9, 2015 at 7:51 AM, Philipp Slusallek <philipp.slusallek at dfki.de > wrote: > Hi Toni, > > There seems to be some confusion here. Our architecture diagram (the > latest/current one is actually > > https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Advanced_Web_UI_Architecture > ). > Show only a single GE, which is 3D-UI. Note that GE is a specification > not an implementation. Also Sync is a separate GE > > Of that 3D-UI GE we have two implementations (GEi), XML3D and WebTundra. > The latter of which is happening also to include an implementation of > the Sync GE. XML3D has been the reference implementation (GEri), though, > for 3D-UI since the beginning. > > I think that it is important to be able to separate 3D from Sync, as > there are many cases where Sync is actually not needed and this is why > these are separate GEs and why have implemented them separately -- but > such that they can be combined nicely, when developers need it > (improvements are certainly still possible and planned). > > YOu are coming from a different point of view where both GEs have always > been come as a bundle -- and that is perfectly fine to do for GEs or > combinations thereof. So we are all set here. > > But you are raising a good point, that our GEs are not as compatible as > they probably could -- or even should -- be. I have raised this in some > of our discussions/emails as a point that we need to address, as the > commission had issues about us maintaining two GEs. I have been able to > defend this and its not been raised as an issue in the review outcome. > So we probably will not see an immediate complaint, but we should > address this going forward. > > If we have time today, we maybe should start this discussion. > > As a quick solution, we could simply create pointers between the two GEs > stating that for some use-cases it does make sense to use them together > and where to find the API documentation to do so. Would that solve you > immediate concerns? > > > Best, > > Philipp > > > > Am 09.09.2015 um 03:46 schrieb Toni Alatalo: > > Hi - yes Torsten is correct and that was agreed, however that's not the > > whole story so I try to clarify the situation here: > > > > WebTundra is the reference implementation of the client core in FIWARE > > WebUI, see architecture diagram at > > > https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Advanced_Middleware_and_Web_UI_Architecture#Architecture_Overview > > . Because it is the only implementation where 3DUI and Synchronization > > are integrated. And essentially for this spec biz: the idea is that > > there is a unified API by which both 3D gfx and synchronization happen. > > > > That means that the developer uses a single API to develop a multiuser > > application. Under the hood the 3D and Synchronization implementations > > take care that the state is both rendered and replicated over the > > network. And optionally the physics are simulated too, either in client > > or server. But typically the developer does not use the GEs separately > > but through a single API: the scene with the entities and components. > > This is unfortunately not reflected well in the GE oriented docs now -- > > the issue was discussed earlier in a thread where I wondered whether we > > miss a GE (this kind of ‘scene api ge’ or so). > > > > Furthermore, a result from old-fiware was that XML3D and Tundra EC-model > > are essentially the same. In both there are components for 3D app > > functionality which are easy for user to add: for example Mesh. These > > are equivalent: > > > > XML3D: > > <mesh src=”cube.json”> > > > > TXML: > > <entity> > > <component type="EC_Mesh"> > > <attribute value="cube.json" name="Mesh ref"/> > > </component> > > </entity> > > > > WebTundra JS: > > entity.addComponent(Tundra.Mesh, “cube.json”); //simplified fictional > > API to illustrate > > > > No matter which syntax you use, the end result is the same: you get an > > entity with a mesh component in your applications memory. So they really > > are the same thing. Not theoretically but that is literally how > > WebTundra works. This is documented in the 3DUI GE spec in the mapping > > part: > > > https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.MiWi.3D-UI#Mapping_Synchronization_GE_data_to_XML3D_objects > > > > That scene model & JS API is documented now in the Synchronization GE. > > But the whole point is that the same API is used for 3DUI. Developers > > instantiate components and define their attributes, and the platform > > takes care that they both a) show in 3D and b) are synchronized over the > > net. So we actually have a single API for the two GEs. > > > > Basically what we want to say in the 3DUI spec is that in Tundra & > > WebTundra we have components such as Mesh and Light. The current XML3D > > oriented spec approximately says that so I’ve figured it is bearable. > > And then the Sync GE specs describe the JS API for creating those > > entities and components. I think it would be clearer though to have a > > single document to tell all that but I’m not sure where we could put > > that in the FIWARE scheme. Perhaps it is OK to have it externally just > > as a realXtend dev doc. And of course in the FIWARE dev manuals. If > > someone has better ideas for handling this though please do tell. > > > > Sync and 3DUI have specific things too but for the basics it’s the same. > > Outside the common part, for example in Sync you can define client > > connection handlers & authentication. And in 3DUI are specifics about > > graphics such as material properties / shader parameters. There details > > differ between the Three.js and XML3D implementations. XML3D.js is > > obviously the reference implementation of XML3D itself, down to such > > rendering details and DOM integration. > > > > But regarding FIWARE WebUI, perhaps the 3DUI spec should document only > > the common part which works for the integrated 3DUI & Synchronization > > solution? What is shared between the WebTundra core components & XML3D > > elements (mesh, light etc. and their params). Then the details about > > materials etc. are external in XML3D & Three.js documentations > respectively. > > > > Hopefully this brings Cvetan and others up-to-speed what these spec docs > > mean from a realXtend perspective. And even better if we find ways to > > clarify the situation. > > > > ~Toni > > > > On Fri, Sep 4, 2015 at 4:30 PM, Torsten Spieldenner > > <torsten.spieldenner at dfki.de <mailto:torsten.spieldenner at dfki.de>> > wrote: > > > > Yes :) > > > > I did the same for FiVES - there is just no Open Spec for > > alternative implementations. > > > > Best, > > Torsten > > > > Am 04.09.15 um 3:27 PM schrieb Cvetan Stefanovski: > >> Ah alright, I seem to have missed that part. > >> In that case, can I just close the WebTundra OpenSpec JIRA issue? > >> > >> On Fri, Sep 4, 2015 at 4:26 PM Torsten Spieldenner > >> <torsten.spieldenner at dfki.de <mailto:torsten.spieldenner at dfki.de>> > >> wrote: > >> > >> Hi, > >> > >> as the Spec is per GE, and not per GEi, we decided on > >> Wednesdays Web UI call that we are going to provide the > >> reference GE implementation spec here, which will come from > >> DFKI and is done with Respec, as discussed with Miguel and > >> Jose before. > >> > >> The WebTundra-Specific JavaScript - API is a specialty of the > >> WebTundra-implementation, and will be linked from the User and > >> Programmers guide, but not be part of the overall GE spec. So > >> there is no Spec for WebTundra that needs to be submitted in > >> the scope of the incoming deadline. > >> > >> @Toni: Feel free to correct me, if I got something wrong here :) > >> > >> > >> Best, > >> Torsten > >> > >> Am 04.09.15 um 3:21 PM schrieb Cvetan Stefanovski: > >>> Hello, > >>> > >>> I prepared the open spec docs for 2D-UI and Interface Designer. > >>> However, I cannot seem to find the previous open spec for > >>> WebTundra, as it is not on any page. > >>> > >>> Toni: can you point out an URL where the open spec for > >>> WebTundra is? > >>> > >>> On Fri, Sep 4, 2015 at 10:12 AM Torsten Spieldenner > >>> <torsten.spieldenner at dfki.de > >>> <mailto:torsten.spieldenner at dfki.de>> wrote: > >>> > >>> Hi all, > >>> > >>> this is a reminder that TODAY is the deadline of having > >>> the Open Spec documents ready. I had a look at the WebUI > >>> Open Specs, and unfortunately, most of them are not in > >>> correct shape (see Miguels email below). As communicated > >>> on several mailinglists last week, the page should not be > >>> created by coarse copy of the contents of the old page, > >>> but by using includes in the Wiki page. See 3D-UI as > example: > >>> > >>> > http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php?title=FIWARE.OpenSpecification.WebUI.3D-UI_R4&action=edit > >>> > >>> Also, as discussed in the Wednesday call, we need to make > >>> sure that ALL GE are documented. Some GE are still > >>> missing content completely. > >>> > >>> Instructions of how to create the Apiary Doc from the > >>> sources will be sent by Miguel during this day. > >>> > >>> Best, > >>> Torsten > >>> > >>> > >>> > >>> -------- Weitergeleitete Nachricht -------- > >>> Betreff: Re: [Fiware] [IMPORTANT]Guidelines for the > Open > >>> Specs (important clarification) > >>> Datum: Thu, 3 Sep 2015 17:25:22 +0200 > >>> Von: MIGUEL CARRILLO PACHECO > >>> <mailto:miguel.carrillopacheco at telefonica.com>< > miguel.carrillopacheco at telefonica.com> > >>> <mailto:miguel.carrillopacheco at telefonica.com> > >>> An: fiware at lists.fi-ware.org > >>> <mailto:fiware at lists.fi-ware.org> > >>> <fiware at lists.fi-ware.org> <mailto: > fiware at lists.fi-ware.org> > >>> Kopie (CC): fiware-chapter-leaders at lists.fi-ware.org > >>> <mailto:fiware-chapter-leaders at lists.fi-ware.org> > >>> <fiware-chapter-leaders at lists.fi-ware.org> > >>> <mailto:fiware-chapter-leaders at lists.fi-ware.org>, > >>> fiware-chapter-architects at lists.fi-ware.org > >>> <mailto:fiware-chapter-architects at lists.fi-ware.org> > >>> <fiware-chapter-architects at lists.fi-ware.org> > >>> <mailto:fiware-chapter-architects at lists.fi-ware.org> > >>> > >>> > >>> > >>> Dear all, > >>> > >>> Two weeks after my first warning I insist that some > >>> people are not getting this right(see my previous message > >>> on the matter below this message). [Security people, > >>> please see the note at the end] > >>> > >>> I was looking at the contents of > >>> < > http://wiki.fiware.org/Summary_of_FIWARE_Open_Specifications_R4>< > http://wiki.fiware.org/Summary_of_FIWARE_Open_Specifications_R4> > http://wiki.fiware.org/Summary_of_FIWARE_Open_Specifications_R4 > >>> and saw that many of you are not following the guidelines > >>> on the Guidelines for R4 > >>> < > https://docs.google.com/document/d/1wa15t2dSEucSA1xD7FyOLpP0ymihYYry0mhALV6GsXU > > > >>> (see section 2.1) > >>> > >>> Please take into account the text after "/*Note that most > >>> of the work is wiki “includes” * /" , it gives you the > >>> key to do this correctly. > >>> > >>> I see that many of you are writing an independent text > >>> for all the page, completely decoupled from the > >>> architecture, which will result in a rejection when we > >>> inspect it. > >>> > >>> Another example of a page that seems well edited (at > >>> least in the respect I refer to): > >>> > >>> * > https://wiki.fiware.org/FIWARE.OpenSpecification.Data.StreamOriented_R4 > >>> > >>> > >>> The wiki source of the page explains very well how this > goes: > >>> > >>> * > https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php?title=FIWARE.OpenSpecification.Data.StreamOriented_R4&action=edit > >>> > >>> > >>> *Tomorrow I will send the instructions to deliver to us > >>> the Apiary Blueprint format to us (section 2.2 in the > >>> guidelines) * > >>> > >>> Best regards, > >>> > >>> Miguel > >>> P.S.: The security people can link the architecture pages > >>> as they are now waiting the leaders to port it (as you > >>> know, the architecture was sent to the EC the other day). > >>> If a GE is new and does not have a page yet, just link > >>> the page name that will exist in the future. Check with > >>> Cyril if there are any doubts. > >>> > >>> El 20/08/2015 a las 10:56, MIGUEL CARRILLO PACHECO > escribió: > >>>> Dear all, > >>>> > >>>> A colleague came to me asking one question and I > >>>> realised that there is a wrong approach in some GEs. > >>>> Fortunately, I took a look and saw that there are very > >>>> few who have posted their contributions to the wiki > already. > >>>> > >>>> The "*Summary of Open specs*" pages work as in previous > >>>> versions. I anticipated that it is a "coarse copy-paste > >>>> from previous versions" implying that the structure is > >>>> similar. For instance, see the source wiki page for the > >>>> "old" Open Specs of the Orion Context Broker: > >>>> > >>>> * > https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php?title=FIWARE.OpenSpecification.Data.ContextBroker&action=edit > >>>> > >>>> > >>>> most of it is "includes" of Architecture pages!!! > >>>> Admittedly, sometimes you will need to shuffle around > >>>> the sections in the architecture to make them uniform > >>>> but this should not be a big deal. > >>>> > >>>> The big work is actually for the other part, the API. > >>>> The "Summary" page should be easy and quick. > >>>> > >>>> This must be a bit new for the new enablers/partners but > >>>> for the others it should be trivial to understand. > >>>> > >>>> Sorry if this was not sufficiently clear in the first > place. > >>>> > >>>> Best regards, > >>>> > >>>> Miguel > >>>> P.D.: It would be arguable whether to using the same > >>>> info on two pages makes sense. We were forced to do this > >>>> after receiving one comment from the reviewers. > >>>> > >>>> > >>>> El 18/07/2015 a las 0:07, MIGUEL CARRILLO PACHECO > escribió: > >>>>> Dear all, > >>>>> > >>>>> My colleague José Manuel Cantera has anticipated how > >>>>> you should edit the Open Specs APIs and this is the > >>>>> major item of work we expect for this part of the 4th > >>>>> Release of the Open Specs. But I will add the > >>>>> information to complete the work. We will proceed like > >>>>> this: > >>>>> > >>>>> AS REGARDS THE APIs > >>>>> ===================== > >>>>> > >>>>> * You will create the APIs following Jose Manuel´s > >>>>> intructions, ideally on APIary. > >>>>> * If you do not use APIary as we expect you will do > >>>>> by default, you are free to do so but it would be > >>>>> trouble for you. This would imply that the > >>>>> automated tools we are creating to produce > >>>>> deliverables would not work for you and you would > >>>>> have to create all by hand and complying strictly > >>>>> with the same templates, etc. We will not accept > >>>>> any delays on the grounds of this, if you do not > >>>>> accept APIry it is fine but then you will need to > >>>>> make the effort to present the same docs in time. > >>>>> * The documents I refer to will be automatically > >>>>> generated from your APIary repository and you will > >>>>> add them to your Github repository. > >>>>> o If you use APIary following the guidelines, you > >>>>> will get the docs as an output of automated > scripts > >>>>> o If you do not use APIARy the process is the > >>>>> same, you will have to edit the docs by hand > >>>>> and upload to Github > >>>>> o Jose Manuel will send the templates for those > >>>>> who refuse to use APIAry when they are ready > >>>>> (getting there but not available yet ...). > >>>>> Those using APIary do not need them. > >>>>> * You _*must*__*n't*_*__*edit the pages linked from > >>>>> this one: > >>>>> o > http://wiki.fiware.org/Summary_of_FIWARE_API_Open_Specifications > >>>>> > >>>>> o At the end of the process we will just put a > >>>>> list of links to the Github repos and this page > >>>>> will just have the list of links. > >>>>> > >>>>> AS FOR THE "SUMMARY OF OPEN SPECS" PAGES > >>>>> ========================================= > >>>>> The work space is this page I just created to start it > up: > >>>>> > >>>>> * > http://wiki.fiware.org/Summary_of_FIWARE_Open_Specifications_R4 > >>>>> > >>>>> > >>>>> Work to do: > >>>>> > >>>>> * This page is a coarse copy-paste from the previous > >>>>> one with slight modifications. The chapter leaders > >>>>> will have to add, delete, modify or whatever is > >>>>> needed to ensure that we have the links for the GEs > >>>>> in their chapters in R4 on this page. There are > >>>>> radical changes to do in several chapters > >>>>> (Security, I2ND and WebUI, for instance) > >>>>> * Each GE owner will have to provide their inputs for > >>>>> his/her GE page linked from here. Please use these > >>>>> sections _*STRICTLY*_: > >>>>> > >>>>> 1 Preface > >>>>> 2 Copyright > >>>>> 3 Legal Notice > >>>>> 4 Overview > >>>>> 5 Basic Concepts > >>>>> 6 Generic Architecture > >>>>> 7 Main Interactions > >>>>> 8 Basic Design Principles > >>>>> 9 Detailed Specifications > >>>>> 10 Re-utilised Technologies/Specifications > >>>>> 11 Terms and definitions > >>>>> > >>>>> * In "9 Detailed Specifications" we just want a link > >>>>> to the Github repository. We will add an > >>>>> explanatory text later. > >>>>> > >>>>> DEADLINES > >>>>> ================= > >>>>> > >>>>> * *July, 24*: For the _*leaders *_to have the links > >>>>> on page ready (if absent, the *_Architect _*will > >>>>> have to do it architect) – I will apply karma on > >>>>> the 27th > >>>>> * *Sept, 4*: The summer is here and most of you will > >>>>> take a few weeks of well deserved break. Let us > >>>>> give a reasonable deadline the *GE owners* to have > >>>>> their pages and all on Github at the beginning of > >>>>> September (on the 4th). > >>>>> > >>>>> Needless to say, the chapter leaders have the duty of > >>>>> following up an ensuring that all is in good order and > >>>>> delivered on time. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Miguel > >>>>> -- > >>>>> > >>>>> Please update your address book with my new e-mail > address: miguel.carrillopacheco at telefonica.com <mailto: > miguel.carrillopacheco at telefonica.com> > >>>>> > >>>>> > ---------------------------------------------------------------------- > >>>>> _/ _/_/ Miguel > Carrillo Pacheco > >>>>> _/ _/ _/ _/ Telefónica Distrito > Telefónica > >>>>> _/ _/_/_/ _/ _/ Investigación y Edifico Oeste > 1, Planta 6 > >>>>> _/ _/ _/ _/ Desarrollo Ronda de la > Comunicación S/N > >>>>> _/ _/_/ 28050 Madrid > (Spain) > >>>>> Tel: (+34) > 91 483 26 77 <tel:%28%2B34%29%2091%20483%2026%2077> > >>>>> > >>>>> e-mail: > miguel.carrillopacheco at telefonica.com <mailto: > miguel.carrillopacheco at telefonica.com> > >>>>> > >>>>> Follow FIWARE on the net > >>>>> > >>>>> Website: http://www.fiware.org > >>>>> Facebook: https://www.facebook.com/eu.fiware > >>>>> Twitter: http://twitter.com/Fiware > >>>>> LinkedIn: > https://www.linkedin.com/groups/FIWARE-4239932 > >>>>> > ---------------------------------------------------------------------- > >>>>> > >>>>> > ------------------------------------------------------------------------ > >>>>> > >>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a > >>>>> su destinatario, puede contener información > >>>>> privilegiada o confidencial y es para uso exclusivo de > >>>>> la persona o entidad de destino. Si no es usted. el > >>>>> destinatario indicado, queda notificado de que la > >>>>> lectura, utilización, divulgación y/o copia sin > >>>>> autorización puede estar prohibida en virtud de la > >>>>> legislación vigente. Si ha recibido este mensaje por > >>>>> error, le rogamos que nos lo comunique inmediatamente > >>>>> por esta misma vía y proceda a su destrucción. > >>>>> > >>>>> The information contained in this transmission is > >>>>> privileged and confidential information intended only > >>>>> for the use of the individual or entity named above. If > >>>>> the reader of this message is not the intended > >>>>> recipient, you are hereby notified that any > >>>>> dissemination, distribution or copying of this > >>>>> communication is strictly prohibited. If you have > >>>>> received this transmission in error, do not read it. > >>>>> Please immediately reply to the sender that you have > >>>>> received this communication in error and then delete it. > >>>>> > >>>>> Esta mensagem e seus anexos se dirigem exclusivamente > >>>>> ao seu destinatário, pode conter informação > >>>>> privilegiada ou confidencial e é para uso exclusivo da > >>>>> pessoa ou entidade de destino. Se não é vossa senhoria > >>>>> o destinatário indicado, fica notificado de que a > >>>>> leitura, utilização, divulgação e/ou cópia sem > >>>>> autorização pode estar proibida em virtude da > >>>>> legislação vigente. Se recebeu esta mensagem por erro, > >>>>> rogamos-lhe que nos o comunique imediatamente por esta > >>>>> mesma via e proceda a sua destruição > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Fiware-chapter-architects mailing list > >>>>> Fiware-chapter-architects at lists.fi-ware.org <mailto: > Fiware-chapter-architects at lists.fi-ware.org> > >>>>> > https://lists.fi-ware.org/listinfo/fiware-chapter-architects > >>>> > >>>> -- > >>>> > >>>> Please update your address book with my new e-mail > address: miguel.carrillopacheco at telefonica.com <mailto: > miguel.carrillopacheco at telefonica.com> > >>>> > >>>> > ---------------------------------------------------------------------- > >>>> _/ _/_/ Miguel Carrillo > Pacheco > >>>> _/ _/ _/ _/ Telefónica Distrito > Telefónica > >>>> _/ _/_/_/ _/ _/ Investigación y Edifico Oeste > 1, Planta 6 > >>>> _/ _/ _/ _/ Desarrollo Ronda de la > Comunicación S/N > >>>> _/ _/_/ 28050 Madrid > (Spain) > >>>> Tel: (+34) 91 > 483 26 77 <tel:%28%2B34%29%2091%20483%2026%2077> > >>>> > >>>> e-mail: > miguel.carrillopacheco at telefonica.com <mailto: > miguel.carrillopacheco at telefonica.com> > >>>> > >>>> Follow FIWARE on the net > >>>> > >>>> Website: http://www.fiware.org > >>>> Facebook: https://www.facebook.com/eu.fiware > >>>> Twitter: http://twitter.com/Fiware > >>>> LinkedIn: > https://www.linkedin.com/groups/FIWARE-4239932 > >>>> > ---------------------------------------------------------------------- > >>> > >>> -- > >>> > >>> Please update your address book with my new e-mail > address: miguel.carrillopacheco at telefonica.com <mailto: > miguel.carrillopacheco at telefonica.com> > >>> > >>> > ---------------------------------------------------------------------- > >>> _/ _/_/ Miguel Carrillo > Pacheco > >>> _/ _/ _/ _/ Telefónica Distrito > Telefónica > >>> _/ _/_/_/ _/ _/ Investigación y Edifico Oeste 1, > Planta 6 > >>> _/ _/ _/ _/ Desarrollo Ronda de la > Comunicación S/N > >>> _/ _/_/ 28050 Madrid > (Spain) > >>> Tel: (+34) 91 > 483 26 77 <tel:%28%2B34%29%2091%20483%2026%2077> > >>> > >>> e-mail: > miguel.carrillopacheco at telefonica.com <mailto: > miguel.carrillopacheco at telefonica.com> > >>> > >>> Follow FIWARE on the net > >>> > >>> Website: http://www.fiware.org > >>> Facebook: https://www.facebook.com/eu.fiware > >>> Twitter: http://twitter.com/Fiware > >>> LinkedIn: > https://www.linkedin.com/groups/FIWARE-4239932 > >>> > ---------------------------------------------------------------------- > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> Este mensaje y sus adjuntos se dirigen exclusivamente a > >>> su destinatario, puede contener información privilegiada > >>> o confidencial y es para uso exclusivo de la persona o > >>> entidad de destino. Si no es usted. el destinatario > >>> indicado, queda notificado de que la lectura, > >>> utilización, divulgación y/o copia sin autorización puede > >>> estar prohibida en virtud de la legislación vigente. Si > >>> ha recibido este mensaje por error, le rogamos que nos lo > >>> comunique inmediatamente por esta misma vía y proceda a > >>> su destrucción. > >>> > >>> The information contained in this transmission is > >>> privileged and confidential information intended only for > >>> the use of the individual or entity named above. If the > >>> reader of this message is not the intended recipient, you > >>> are hereby notified that any dissemination, distribution > >>> or copying of this communication is strictly prohibited. > >>> If you have received this transmission in error, do not > >>> read it. Please immediately reply to the sender that you > >>> have received this communication in error and then delete > it. > >>> > >>> Esta mensagem e seus anexos se dirigem exclusivamente ao > >>> seu destinatário, pode conter informação privilegiada ou > >>> confidencial e é para uso exclusivo da pessoa ou entidade > >>> de destino. Se não é vossa senhoria o destinatário > >>> indicado, fica notificado de que a leitura, utilização, > >>> divulgação e/ou cópia sem autorização pode estar proibida > >>> em virtude da legislação vigente. Se recebeu esta > >>> mensagem por erro, rogamos-lhe que nos o comunique > >>> imediatamente por esta mesma via e proceda a sua destruição > >>> > >>> > >>> _______________________________________________ > >>> Fiware-webui mailing list > >>> Fiware-webui at lists.fi-ware.org > >>> <mailto:Fiware-webui at lists.fi-ware.org> > >>> https://lists.fi-ware.org/listinfo/fiware-webui > >>> > >> > >> -- > >> Torsten Spieldenner, M.Sc. > >> > >> Tel.: +49 6 81 / 8 57 75 - 77 48 > >> Fax.: +49 6 81 / 8 57 75 - 22 35 > >> > >> Internet: http://www.dfki.de/web/forschung/asr/ > >> > >> ------------------------------------------------------------- > >> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH > >> Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany > >> > >> Geschaeftsfuehrung: > >> 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 > >> ------------------------------------------------------------- > >> > > > > -- > > Torsten Spieldenner, M.Sc. > > > > Tel.: +49 6 81 / 8 57 75 - 77 48 > > Fax.: +49 6 81 / 8 57 75 - 22 35 > > > > Internet: http://www.dfki.de/web/forschung/asr/ > > > > ------------------------------------------------------------- > > Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH > > Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany > > > > Geschaeftsfuehrung: > > 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 > > ------------------------------------------------------------- > > > > > > _______________________________________________ > > Fiware-webui mailing list > > Fiware-webui at lists.fi-ware.org <mailto: > Fiware-webui at lists.fi-ware.org> > > https://lists.fi-ware.org/listinfo/fiware-webui > > > > > > > > > > _______________________________________________ > > Fiware-webui mailing list > > Fiware-webui at lists.fiware.org > > https://lists.fiware.org/listinfo/fiware-webui-new > > > > -- > > ------------------------------------------------------------------------- > 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 > --------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-webui/attachments/20150909/6d4ff4dd/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy