Bertrand/all, Thanks for the input both here and in the other thread.
Based on a (commonly called) "1.0" data format (which essentially is fully backward compatible with the W3C DDR specification used by OpenDDR and other libraries) this is certainly the case. All prior "parsing" solutions which Reza or others may have maintained elsewhere also used the OpenDDR data structure and many now are backed by the DeviceMap successor to that format. A so called "2.x" format is yet to define by the entire team in a careful design process similar to what we see e.g. at Tamaya and other projects. As a matter of fact the separation into 3 separate XML files has always existed, too: - https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/BrowserDataSource.xml - https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/DeviceDataSource.xml - https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/OperatingSystemDataSource.xml Only DeviceDataSource has ever been used. The other files are used by the W3C DDR Implementations and the API offers full access to it. Like with 2 other XML files (including DeviceDataSource) "parsing" these files from non W3C clients is certainly possible, too. There are properties that go beyond the "Core W3C DDR Vocabulary", almost all of the "device_os*" or "is_*" ones were added by communities like OMA (Open Mobile Alliance) and its members and used by a number of W3C DDR implementations. Some call it differently, so there is room to rename or remove some. Especially things like "device_os_version" turned out to be less effective, it is in reality mostly a "factory_os_version" "default_*" or similar, the actual OS version in the User Agent is different. And at least the W3C client properly amends that to the detection based on the UA string if it changed from the factory default. Beside a possible security problem by bundling an "admin console" directly with any client (as the classifier/parser one currently does) there are other security aspects to pay attention to, e.g. how to ensure, a remote data source picked up by a loader is trusted and not tampered with or spoofed. HTTPS instead of simple HTTP could be a start, I guess we need to look into that in more detail. So while at first sight "remote access" to device data may seem appealing (and since the recognized device information is currently identical based on the same source, that is the only real difference for users that they may access data from "anywhere" in the web rather than a local or network drive in a company network, in theory that could also be WAN from another part of the world;-) controlling and protecting that freedom is important to every serious enterprise user. Thus the W3C DDR implementation which was designed by those kinds of large enterprises offers more safety by not loading "random" data sources anywhere in the Web. There is no reason not to offer the 1.x compliant W3C DDR implementation in a 1.x version of DeviceMap. I brushed up a few things, e.g. consistent logging (Log4J 2, if we all prefer it may use Java's internal logging, but for now I just replaced SLF4J with Log4J 2 which is also an Apache project;-) so it is release ready as of now. If a future "2.x" data drastically moved away from what W3C defined and uses, the W3C implementation may at some point no longer use this file. We see that with vendors like DeviceAtlas, but at least they also still offer both clients for 2 different data formats. Another reason to give all the users of W3C compliant solutions a chance to use DeviceMap (because their vendor is too expensive not up to date or simply ran out of business;-) Through OMA defined attributes (not because it was directly derived from it) all users betrayed by WURL and maybe left with a data source from 2011 also find the W3C DDR version closer to "home". I'm happy to take charge of this component, also defined it in JIRA (till Reza at least deleted the Component Lead role there;-|) Since it is fairly stable and mature having been developed since late 2011 (and 2012 at DeviceMap) there will be less effort here than with the other client(s) also for different languages. I don't discourage others from helping but there will be less to do since the codebase is more established already (especially by the OpenDDR team) Regards, Werner On Mon, Jan 5, 2015 at 9:40 AM, Bertrand Delacretaz <[email protected]> wrote: > Hi, > > It looks like there's disagreement about maintaining and releasing one > or two Java clients that use the DeviceMap data. > > I don't have a strong opinion myself - if we have volunteers to > maintain two clients, why not. > > The main problem IMO is whether both clients can use the same data set. > > I haven't been able to review all the recent discussions in detail, > but it seems like one recent commit broke one the clients while > improving the other - if that's the case, then something needs to be > fixed, or worst case two slightly different variants of the device > data set might need to be maintained. > > What do people think, can we technically live with two java clients, > possibly maintained by different people, or are there technical > hurdles that prevent that? > > -Bertrand >
