devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <>
Subject Re: Clients
Date Wed, 01 Apr 2015 16:15:32 GMT
And yes, data is the most important piece. Should anybody decide to write a
completely independent client on GitHub, BitBucket, etc. why not, that
would also be fine and does not compete with any language support at Apache
as of now. The Clojure module seems a simple wrapper (around the 1.0
Classifier) but we might see clean room rewrites similar to the ones for
.NET that take inspiration from the Java client or use a different
approach, let's see.

We should offer help by those who sounded interested to participate.
Whether they contribute to data, one or the other client is up to them, the
more the better. It'll probably never be a "mass project" like say
OpenOffice or Cordova, but having 5 or 6 people commit instead of 1 or 2 at
times certainly sounds better for the whole project and community.


On Wed, Apr 1, 2015 at 6:03 PM, Werner Keil <> wrote:

> What Bertrand mentioned is, nobody can unwrite history, e.g. deleting or
> destroying prior clients.
> If a 2.0 client in any language was to support or not support standards
> like W3C DDR Simple API is completely up to each API and contributors.
> In fact I also highlighted at codemotion, that given W3C only made this
> available as a Java API, implementing it is almost like Java standards
> under the JCP, it's for Java only and they aren't going to write a .NET API
> as it seems.
> Therefore let's not forget other languages. If a 2.0 data structure was to
> be shaped as part of DeviceMap by everyone who is willing to participate,
> then at least the 3 (or including Browsermap 4, but it doesn't directly
> interact with the DDR in most cases) languages should support it sooner or
> later. Nobody has done much after Eberhard started these 2, but expecially
> for the live demos I brushed out some issues and edges, too. Last but not
> least confirming a recent VS Community Edition 2013 or above works for
> anybody who can download that from Microsoft (it's free;-) Should there be
> a significant overhaul towards a new data format, I'd be happy to help also
> on the .NET side, but hope, Eberhard may also be able to continue some of
> that. The .NET versions are not simple clones, e.g. the issue of a
> redundant console baked into the Java client is still unresolved there
> though we had patches by Volkan (who's happy to help but so far nobody
> discussed new committers like him to help) to resolve this. The .NET
> solutions have properly separated a "Client" and "Console". Therefore it's
> not just about a new data format or new clients against it, simply
> addressing some problems of the existing ones should also not be forgotten.
> Werner
> On Wed, Apr 1, 2015 at 5:46 PM, Reza Naghibi <> wrote:
>> Sorry, my apologies, browsermap has been released.
>> On Wed, Apr 1, 2015 at 11:44 AM, Reza Naghibi <> wrote:
>> > So I just want to have a final discussion here before I come to my own
>> > personal conclusions regarding my role in this project. This way moving
>> > forward will be more clear.
>> >
>> > So it seems like there are 2 project directions being proposed:
>> >
>> > One direction, supported by Werner and Bertrand, has this project
>> > positioned as offering and supporting multiple device detection
>> clients. So
>> > I like to think of it as a device detection api buffet, a product
>> polyglot
>> > even. Our users simply choose an option as they see fit. The clients
>> that
>> > exist are the legacy OpenDDR client (not sure what else to call it since
>> > there is no official release other than source code in github and apache
>> > svn), the 1.x Java client released under DeviceMap, a cloned .NET
>> client,
>> > and Browsermap, a javascript client which I believe is in an un released
>> > state. Obviously my 2.0 work could fall under this as well.
>> >
>> > The other direction, which is the direction I supported, is moving away
>> > from all the above clients and starting fresh with a 2.0 framework of a
>> > client specification. The device data would be migrated to pattern
>> domains
>> > and we would expand to browsers, operating systems, and potentially
>> other
>> > new domains. The specification will allow for clients to be written and
>> > tested in a language and domain independent way. All the above clients
>> in
>> > the first point (OpenDDR, DeviceMap 1.x, browsermap, etc) will no
>> longer be
>> > supported and users will have to use them as released or migrate to 2.0.
>> > The same goes for the device data, new work would be on the 2.0 domains
>> and
>> > no backporting would be planned.
>> >
>> > Even if we all come to agreement here, I am not making any promises
>> > regarding my role moving forward. I just want to have a clear, level
>> headed
>> > discussion using facts and opinions. If other people here have other
>> views
>> > or opinions, share them.
>> >

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