Hi Thomas, I have raised concern regarding the support of current users (within the FI-PPP!) of existing GEis. This is a real question that we face and that that people will certainly approach me with. Why do you have a problem with that very relevant issue? Your write: "Agreement is to put ALL existing implementations on hold". I cannot agree with the statement in this strict form for the above reasons. All I am arguing is that some (smaller) efforts be reserved for support of existing and actively used technology. I also made it clear that I fully support the focus of our work on the Java API as suggested, Just not exclusively. I hope this is fine with all. Best, Philipp Am 24.09.2014 um 11:04 schrieb Thomas Michael Bohnert: > Philipp, > > I will stop this discussion here. It is pointless and a waste of time. > > We are a team and we have to consider the exact context and > organisationl structures and responsibilities. > > As I have said so many times in the past, we all have good reasons why > this is good and this is bad and this is better than this or that. > > But the point now is to stop this waste of time with arguing but to > start something that is first and foremost driven by a joint effort and > team. > > I really hope you can accept this and look forward to your contribution > as a team member. > > Best - Thomas > > > > > On 09/24/2014 06:39 AM, Philipp Slusallek wrote: >> Hi all, >> >> Sorry Thomas, for some reason I had not seen your email before I sent >> mine last night. Thanks for the update. Has the text you sent been >> agreed upon by Chapter 1.8 at the meeting in Madrid or is this more a >> summary of the discussions that took place at the meeting? >> >> >> Regarding the external expert: I believe Juanjo himself is probably one >> of the best experts we could find. If he suggested others, this is >> probably fine as well. Who is it that you are contacting now? >> >> >> While I very much agree (as I already told you) to focus on the Java >> version, I disagree strongly that we should stop all activities on the >> existing implementations. We must at least maintain the current >> technology and support it where necessary. >> >> Let's not forget that there are implementations that make active use of >> KIARA. They are within FI-WARE (Sync GE, CH. 1.5) as well as running >> demos within the FI-Content and FITMAN projects that make use of the >> existing KIARA GEi. Even more uses are planned within the next few >> months. >> >> Abandoning these fully working GEs without any technical reasons for >> doing so, would be damaging to FIWARE and the GE process. As you state, >> the Java version (especially if we start from an empty page) will take >> significant time to become available (you have even talked about one >> year). This is not acceptable for the existing users of the technology. >> Additionally, in those projects the C/C++ interface is needed, which >> would likely take even longer to become available. >> >> Also I see no impact whatsoever that the "old" implementationcould have >> on the new Java API. Once we have agreed on a new API for Java, it >> should not be too difficult to backport that to the current C/C++ >> version (at least if we keep that goal in mind during our discussion, >> which we should do anyway). Given the flexible design of current KIARA >> implementation, we should even be able to do so without having to >> abandon the current API and have them coexist for compatibility until >> existing users had a chance to switch over. >> >> Also there should not be any reason that the new Java version and the >> "old" implementations cannot interoperate, even while they are using >> different API approaches. So, I see also no reason that the "old" design >> would limit how we design the new Java API and implementation (which >> seems something that Jaime is very worried about). >> >> So unless someone comes up with solid technical reasons for abandoning >> the current work (which I cannot see and which have never been presented >> since we started our working on KIARA), we should refrain from >> suggesting to waste EU money that has been spend on the current >> implementations. >> >> To be clear, I am perfectly fine is focusing the current development on >> Java (as we have started some time ago already), I am just opposing to >> abandon the existing work as your text seems to suggest. >> >> >> Best, >> >> Philipp >> >> >> Am 23.09.2014 um 12:19 schrieb Thomas Michael Bohnert: >>> Dear all, >>> >>> Nice to see that there is so much energy behind our proposal to start >>> over with a Java version. If we continue like that there will be soon a >>> very nice product that serves the needs of our primary customers - that >>> is the FIWARE community. >>> >>> About the next steps. >>> >>> First, we need to complete the hand-over from MIWI to I2ND. This >>> includes all the stuff agreed upon during the WPL/WPA meetings, like new >>> mailing lists, etc. But this is mostly admin stuff. >>> >>> One item is the weeky KIARA meeting. This is now linked to Task 1.8.3 >>> and to be taken over by eProsima (Jaime?). That means to prepare agendas >>> in advance, take minutes, record action items, report to the WPA/WPL, >>> and any other task related to the task leadership. >>> >>> Regarding the technical directions to be taken. Agreement is to put ALL >>> existing implementations on hold and to start over with the JAVA >>> version. Starting point is a blank page but we will carefully analyze >>> existing code once we have agreed on the design, i.e. issues first and >>> foremost the KIARA API. >>> >>> About the KIARA API. Here the most important issue is to define an API >>> that meets the expectations of professional software developers. Since >>> we have very good expertises in the team, with a broad spectrum of >>> know-how and experiences we need to find a way to consolidate this into >>> one approach and ultimately specification. One element in achieving this >>> is to consult an external expert that will take a fresh and independent >>> view on things and thus secure a design that meets this requirement. The >>> exact candidate is not yet decided (do you have proposals?) but there is >>> already one person we know about and we currently are contacting. >>> >>> Action items: >>> Jaime - please prepare an agenda for coming Friday meeting, share it at >>> least a day before with the team such that we can add items to the >>> agenda in advance. >>> >>> We will discuss any aspect in next Friday's meeting, that is technical >>> aspects as well as implementation and procedures on task level. >>> >>> Thanks for your contributions and commitment in advance! >>> >>> Christof and Thomas >>> >>> On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: >>>> Hi Philipp, >>>> >>>> This time we are going to start with the design, and not with the >>>> code, and this design should be externally approved. Yes we should >>>> start with a blank page. >>>> >>>> We didn't developed any document. Basically the Java Idea and the >>>> external audit has come from Juanjo. >>>> >>>> We are working now in a proposal (design, spec) of API. Next >>>> Friday meeting, we should start talking about the first design tasks >>>> of JAVA KIARA. >>>> >>>> Our main goal should be the usability, because we need something >>>> stable and easy within one year. >>>> >>>> Regards, >>>> Jaime. >>>> >>>> >>>> -----Original Message----- >>>> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >>>> Sent: lunes, 22 de septiembre de 2014 16:07 >>>> To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List >>>> Subject: Re: [Miwi-middleware] KIARA/Java on github >>>> >>>> Hi Jaime, >>>> >>>> Java was important for us before and Dmitri has worked on this >>>> implementation for quite some time now. we are ualready sing this now >>>> for another project. But changing it for better versions is always a >>>> good thing and we are very open for it. >>>> >>>> Please do not blame us for having already done some of the work that >>>> is now becoming relevant also for the project as a whole. >>>> >>>> You/we do not have to use this directly, but I see this as an >>>> interesting basis that we can use as a starting point for our >>>> discussions. This is why we are making it available for all to look at >>>> (and please do so). >>>> >>>> Having something that is already working and is already compatible >>>> with our previous work is (at least from my point of view) a better >>>> place to start than a blank page. I hope you and others agree. >>>> >>>> As in the C/C++ version we are very open to suggestions and >>>> alternative interfaces and implementations. So please feel free to >>>> suggest those, ideally directly with your implementation. Fortunately, >>>> we will not have the C/C++ issues, so we should be in a much better >>>> place to collaborate based on comparing each of our concepts and >>>> actual implementations of them. >>>> >>>> I am looking forward to a closer collaboration within FI-Core. >>>> >>>> BTW, at the Kickoff you have apparently developed a document >>>> describing how you (as in KIARA group) would want o work together. We >>>> have not been in the loop and so it would be good to get that >>>> document, so we are able to comment (and hopefully just agree to it). >>>> >>>> >>>> Best, >>>> >>>> Philipp >>>> >>>> >>>> >>>> >>>> Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >>>>> Dmitri, we are not going to make the same mistake twice. >>>>> >>>>> First we have to define what we want to do, an API that should be >>>>> externally approved, the different modules, and then start to assign >>>>> tasks. >>>>> >>>>> Don't start just writing code without any design consensus and >>>>> later try the other parties to follow you. >>>>> >>>>> Regards, >>>>> Jaime. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: miwi-middleware-bounces at lists.fi-ware.org >>>>> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri >>>>> Rubinstein >>>>> Sent: lunes, 22 de septiembre de 2014 13:10 >>>>> To: KIARA Mailing List >>>>> Subject: [Miwi-middleware] KIARA/Java on github >>>>> >>>>> I just made KIARA/Java v0.1 available on the github: >>>>> >>>>> https://github.com/dmrub/kiara-java >>>>> >>>>> License: LGPL version 3 >>>>> >>>>> Current features: >>>>> >>>>> Supported transports: HTTP 1.1, TCP Block Transport >>>>> >>>>> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >>>>> serialization) >>>>> >>>>> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the >>>>> KIARA C/C++ version. >>>>> >>>>> Example applications are in: >>>>> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >>>>> >>>>> Best, >>>>> >>>>> Dmitri >>>>> _______________________________________________ >>>>> Miwi-middleware mailing list >>>>> Miwi-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>> >>>>> ----- >>>>> No virus found in this message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: >>>>> 09/08/14 Internal Virus Database is out of date. >>>>> _______________________________________________ >>>>> Miwi-middleware mailing list >>>>> Miwi-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>> >>>> >>>> >> >> > -- ------------------------------------------------------------------------- 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 -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: <https://lists.fiware.org/private/miwi-middleware/attachments/20140924/a0a7653e/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy