Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAAGawe1SXWuo0RycR3d0mFp89aCarsYSTR2YyWqM7F0E6gkDcQ@mail.gmail.com>
References: 
 <CAKuYhJsoDchqvJTgJcBAkimqzagE=G9gsyBy30acU+pDLWBXSA@mail.gmail.com>
	<CAAGawe19XW_pLWxUSV75+URbs9RfLPSUoG3vLasL9BK1mc3G4g@mail.gmail.com>
	<CAAGawe3soif21zAC4Q0p49qWKDkD1fPL1btm=8tTiizAiBm9Pg@mail.gmail.com>
	<CAKuYhJs355fSabVkRdgO1quRqpgVHa8O2ME-kPfDcJRL0aXipg@mail.gmail.com>
	<CAAGawe10zPp=Aomz-_VS0ksntEf4U4SDR==2FX5Mr5q4mobr1w@mail.gmail.com>
	<CAEWfVJmhEW8=yp89O+_RMu2RTwbbrFbModnfGgZn2Pr6ZF-Z+w@mail.gmail.com>
	<CAAGawe0ZJq_MALS-OvoEeyOxGt+hZnpBt_Uo8v8pfCP9FEE9oA@mail.gmail.com>
	<CAEWfVJkE3dbrZSK77L+UsMwm_2waz+2P=4QkuqopbyBx477dPQ@mail.gmail.com>
	<CAAGawe1SXWuo0RycR3d0mFp89aCarsYSTR2YyWqM7F0E6gkDcQ@mail.gmail.com>
Date: Thu, 6 Aug 2015 13:49:53 +0200
Message-ID: 
 <CAAGawe1vrYuJUcm4sZmCieXTFKfW4ruSZEF7arZCNxK8h5P0jQ@mail.gmail.com>
Subject: Re: 2.0 reference client
From: Werner Keil <werner.keil@gmail.com>
To: dev@devicemap.apache.org
Content-Type: multipart/alternative; boundary=001a113cd1f4120569051ca31e24

--001a113cd1f4120569051ca31e24
Content-Type: text/plain; charset=UTF-8

As mentioned, the "2.0 reference client" (unlike new data definitions)
should probably not be under /trunk/clients/2.0 but /whiteboard/rezan,
because
https://svn.apache.org/repos/asf/devicemap/trunk/clients/2.0/reference/src/DeviceMapClient.java
clearly shows, it not only relies on some proprietary build scripts and
environment specific to just a single person's computer.

Leaving the nested if spaghetti-code aside (the parent Apache POM does not
recommend plugins like FindBugs, CheckStyle, etc. but projects may still
use them if they care) all classes are in an anomymous package;-O

Apache doesn't seem to have an official package naming convention like
Eclipse (https://wiki.eclipse.org/index.php/Naming_Conventions) there are
only (now retired) projects like Harmony that did it on its own
https://harmony.apache.org/subcomponents/classlibrary/pkgnaming.html (also
based on Eclipse) but when it comes to Java packages, every proper Apache
project, even those still incubating should follow

I won't bother touching it (as agreed;-) but in this state, I won't bother
looking at it further or even mention it at ApacheCon or similar occasions
either.
It is no more than a "private POC" thrown into the SVN by mistake, at least
in this location.

This is in no way ready to be released or even proposed to the PMC! Nor
called "Reference Client" or "Reference Implementation".


For JavaScript, there is little code, but while there are coding
conventions (e.g. by "JSON Father" Douglas Crockford who was a fellow
speaker at Dutch Mobile Conference 3 years ago) no strong notion of package
at least for individual files exist. If anything was to be seen by the
Node.js and related communities, it has to be published on NPM (once there
was an official release)

There is no "devicemap" module as of now
https://www.npmjs.com/search?q=devicemap

but at least one that seems compatible with DeviceMap 1.0 and its precursor
OpenDDR as well as other solutions like 51degreeMobi or WURFL:
https://www.npmjs.com/package/responder

The GitHub repositories or Travis CI seem gone, but like MavenCentral, once
a module is deployed there it remains in it pretty much forever.

Regards,
Werner

On Mon, Aug 3, 2015 at 5:10 PM, Werner Keil <werner.keil@gmail.com> wrote:

> 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 <
> bdelacretaz@apache.org> wrote:
>
>> On Mon, Aug 3, 2015 at 4:25 PM, Werner Keil <werner.keil@gmail.com>
>> wrote:
>> > ...So examples/x.y is clearly for all who care...
>>
>> No problem with that as far as I'm concerned.
>>
>> -Bertrand
>>
>
>

--001a113cd1f4120569051ca31e24--