devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Clients
Date Wed, 01 Apr 2015 16:03:39 GMT
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 <rezan@apache.org> wrote:

> Sorry, my apologies, browsermap has been released.
>
> http://devicemap.apache.org/download/
>
>
>
> On Wed, Apr 1, 2015 at 11:44 AM, Reza Naghibi <rezan@apache.org> 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.
> >
>

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