The clients will definitely support W3C DDR spec via a wrapper class. Just havent gotten that far yet.
________________________________ From: Werner Keil <[email protected]> To: "[email protected]" <[email protected]> Sent: Saturday, April 5, 2014 2:35 PM Subject: Re: Better documentation. Magudi/all, Thanks for the discussion and suggestions. We clearly need an approach to easier device data updates. E.g. you can visit http://babel.eclipse.org and add messages to Eclipse projects without having to check out .properties files, Java code or similar. That is where we could lower the bar for people to contribute these kinds of things. Hopefully Bertrand or those in regular touch with the Apache Board or legal entities may be able to tell, if Apache allows such contribution by those who registered (similar to JIRA there it already works) and maybe confirmed their right to contribute in an online form, but may not need the heavy duty full contributor agreement required for full commit rights. >Myself and Eberhard spent some time last year rewriting the core clients. While that effort was successful, we kind of got bogged down in some of the >data correctness of the clients. Its not that the new clients aren't correct, they are just different than the legacy OpenDDR clients. So they aren't a drop in >replacement, rather, its a rewrite. In my opinion, everything legacy should probably be discarded code wise. I can easily do this, but see my next point... After just going over all these and working examples I'm afraid I have to disagree here. At the moment these client modules neither implement the W3C DDR spec, nor are there working demo cases for these new client libraries. Even if those came to exist and work properly, true W3C compatibility shouldn't be abandoned or considered "legacy". If optimized libraries provided an advantage, using the same device data, why not, but the W3C complient modules I just improved and added to the main Maven repository should stay. Whether some are considered "stable" thus not changed as much as others, that would be fair, but the W3C Simple DDR client is a "spec" we shall not abandon. I know the Web Service app Reza contributed is used on the DeviceMap site, I e.g. pointed the audience at JavaLand to it, since the time got a bit short to run it there on my own computer, though it also works. I fixed dependencies to use the new DDR Simple imlementation from the DeviceMap repo. I am not sure, what the other "Website" does, but unlike the "Java Web Service" I believe it doesn't work at the moment. Likely in June I could get a chance to present DeviceMap here in Germany at a User Group meeting. Regards, Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Java Godfather Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil * IoT Day: 9 Apr 2014, Zürich, Switzerland, Werner Keil, JCP EC Member, JSR 363 Co Spec Lead will present "JSR 363 - Units of Measurement API" * Developer Week: 14 Jul 2014, Nürnberg, Germany. Werner Keil, JCP EC Member, Agile Coach, DevOps Guy will present "Triple-E' class Continuous Delivery" (GER) On Sat, Apr 5, 2014 at 7:47 PM, gopal kris <[email protected]> wrote: > To understand, the website > 1.needs to allow the users to enter the info of the make and user agent > details. > 2.developers will review the data and approve > 3.then it gets added to ddr data. > > I can take this up. i would need some help on understanding the current > approach to add ddr data and how it is stored. > > Regards > magudi > > > > > > > -----Original Message----- > > From: Reza [mailto:[email protected]] > > Sent: Saturday, April 05, 2014 10:21 PM > > To: venkata kiran surapaneni; [email protected] > > Subject: Re: Better documentation. > > > > Website technology: sure, I agree. But its always best to use apache > > technology :) Since the website will be centered on a client, you are > going > > to have to use .NET or Java. Since .NET requires Microsoft licenses, I > > think that leaves us with Java... > > > > wire frames: No, I do not have any. Im thinking just some basic screens > > and forms will do. > > > > SVN: > > > > .NET and java clients: > > https://svn.apache.org/repos/asf/incubator/devicemap/trunk/devicemap/ > > javascript browsermap client: > > https://svn.apache.org/repos/asf/incubator/devicemap/trunk/browsermap/ > > > > OpenDDR data: > > https://svn.apache.org/repos/asf/incubator/devicemap/trunk/data/ > > > > > > So if someone wants to take a stab at the website, just announce what you > > plan on doing here on the list so people are aware and can coordinate as > > needed, and as always show progress. When you get a good prototype up and > > running, we can review and then if all is good, migrate it into the > project > > and then discuss how we move everything further (ie roadmap). > > > > Thoughts? > > > > > > ________________________________ > > From: venkata kiran surapaneni <[email protected]> > > To: [email protected]; Reza <[email protected]> > > Sent: Saturday, April 5, 2014 12:34 PM > > Subject: Re: Better documentation. > > > > > > > > Hi, > > > > I agree with the use cases proposed. I don't think the > technology > > used to create the website matters. It can be .net, Spring MVC or any > > thing. I think the convenience of the developer who ever takes the > > responsibility should be deciding factor for now. When the library is > > released and is doing good, if required the website can be modified if > > required. I don't think this website is complex. > > > > I think some one needs to create a wire-frame sketches on how the website > > would look so that every one can have a look at them and provide the > > feedback. It would make the life easier for who ever is implementing the > > web site and reduce rework. > > > > While we are discussing the options to make this library more user > > friendly, I think we need to look at the code bases also. The structure > in > > which they are committed to svn are confusing(partly make be due to lack > of > > documentation). If possible each component in this should have its own > > repository. Is this some thing that can be considered ? > > > > > > > > Thanks, > > --Kiran > > >
