devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <>
Subject Re: 2.0 reference client
Date Mon, 03 Aug 2015 15:10:49 GMT
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:

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 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:;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:

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.


On Mon, Aug 3, 2015 at 4:29 PM, Bertrand Delacretaz <>

> On Mon, Aug 3, 2015 at 4:25 PM, Werner Keil <> wrote:
> > ...So examples/x.y is clearly for all who care...
> No problem with that as far as I'm concerned.
> -Bertrand

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message