Good to hear. As offered earlier, everyone, whether they can make it to my session in Budapest or not is welcome to propose new/changed pages based on the most recent slides from Rome: http://de.slideshare.net/keilw/apache-devicemap-codemotion-roma-2015
I'd be more than happy to crop some of the WURFL images since in essence page 16 says all about them and their license situation;-) Similar with benchmarks, if we got more recent ones, then please provide them if you're able to share them publicly. Ideally with a codebase allowing the audience to run it and confirm they're not faked. While it would be a bit of a stretch, if the Core Vocabulary properties as found in http://www.w3.org/TR/ddr-core-vocabulary/#sec-properties remain in the JSON format (similar to how other vendors who offer JSON files, too seem to respect those) then a 2.0 data repository regardless of its format could still be called "W3C compliant" at least regarding the Core Vocabulary. Implementing the W3C DDR Simple API on Java is just one aspect, unrelated to other standards or definitions by W3C or others. The Portlet Standard and EG has its own requirements, e.g. it must only refer to other JSRs (like CC/PP) or at most the underlying W3C standards. On an API level it cannot expose something on "org.apache" since other implementations may chose to implement the standard in their own different way, if they want to use DeviceAtlas, WURFL or whatever under the hood in their commercial product, so be it. Whether the RI (Apache Pluto) uses DeviceMap libraries or just the data files, we'll see. As of now there's a Pluto3 early prototype, we'll see what it may use. Should ApacheCon attendees be interested to provide new language binding, I suggest we offer something like Tamaya Sandbox: https://git1-us-west.apache.org/repos/asf?p=incubator-tamaya.git;a=tree;f=sandbox;h=0cfc8b5cc116fff1096ae7d1d4f6b7199191f8f8;hb=HEAD for people to play with or adopt. Which version/format of the data they want to use, I don't think restricting it there makes sense. As mentioned, DeviceMap is far from being my only talk, so "I have a lot to say" there based on accepted talks;-) We're going to present Groovy support for JSR 354 based on work done in a similar "sandbox" at JavaMoney: https://github.com/JavaMoney/javamoney-shelter/tree/master/groovylang-support While I also volunteered to help with Groovy support (still do) if people who work more with Groovy/Grails than I do want to help, we should not discourage them either but offer them a place. They may not be able to commit directly, but e.g. (since we still use SVN) attach patches to a JIRA story just like Volkan or others did before e.g. he became a committer. The "sandbox" (could also be under /clients) or /trunk, whatever you prefer) makes it easier to add new languages without having to worry about the whole "1.0 vs. 2.0" confusion. After all it's XML or JSON and if a client or language binding wants to support both, it could be confusion and disruption to those having to decide. Werner On Mon, Aug 3, 2015 at 4:29 PM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > On Mon, Aug 3, 2015 at 4:25 PM, Werner Keil <werner.k...@gmail.com> wrote: > > ...So examples/x.y is clearly for all who care... > > No problem with that as far as I'm concerned. > > -Bertrand >
