devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <re...@apache.org>
Subject Re: Clients
Date Wed, 01 Apr 2015 22:47:42 GMT
ok, you kind of skirted the main question which was *what is your roadmap
for this year and beyond*... This is important because if I am to continue
with this project, I need to know what your plans are. If its going to be a
lot of hand waving and objections, just forget it.

I dont mean to beat this thread to death, but I should have called for more
specifics than the theoretical path we took.

So I will answer my own question, my planned roadmap: 1.0.3 data, then 2.0
which will be spec driven, multi data domain, multi language. Bury 1.x and
the past.

Who drives my requirements, me, but I have the privilege of talking to
several large web operators (Alexa top 500) a week. So I have my hand on
the pulse of how these web sites and web infra work:

-backend device detection is pretty much dead (however there are always
exceptions like ad placement). Dead as in the majority isnt investing
resources into projects which render UIs on servers. UI rendering is pretty
much all Javascript based and backend data driven. This means that the
future is Javascript code and JSON data. Browsers and operating systems are
now important.

-device detection is moving closer to routing fabric, so if anything, the C
client is really important.

-devices are stabilizing, so detection is becoming simpler and easier. This
will change when a new class of devices become widespread and change things
like phones did. But who knows when this next wave will arrive.

-backends are purely data, ie: wrappers around databases. I feel there are
new opportunities here like security and who knows what else. So having a
pattern framework ready to move into new possibilities is good.

So to summarize, less devices, more Javascript, more browser, more os, and
more generic frameworks across backend languages.

As stated before, im really over all of this, but its worth discussing, who
knows, maybe there is hope.


On Wed, Apr 1, 2015 at 5:57 PM, Werner Keil <werner.keil@gmail.com> wrote:

> The more languages support our data, the better,so anybody should favor a
> polyglot approach.
>
> Compared to OpenDDR the real world usage and adoption by other projects
> still makes the Classifier clients pretty young and fairly used.
> Bertrand can best speak for where he uses the data, but it sounds from what
> he said about the importance of DDR data as opposed to clients, if he or
> others at Adobe use it, they probably won't use any of the Java APIs
> provided with DeviceMap.
>
> You'll find more 3rd party repositories wrapping or re-implementing OpenDDR
> for various languages (from Perl or PHP to Lisp) than DeviceMap is even
> used on GitHub including BrowserMap mirrors.
>
> DetectRight does not have an Open Source device repository, but a fairly
> polyglot approach to clients for their Web Services:
> https://github.com/DetectRight
> However, DetectRight probably has one of the most diverse offerings:
> http://www.detectright.com/cloud-detection.html
>
> W3C Core or W3C + DeviceAtlas are all W3C compliant, so essentially it's
> similar to DeviceMap's data set. So some of the biggest names in the
> industry (DeviceAtlas or DetectRight aside from commercial WURFL clearly
> all have a big market share) rely on the W3C compliant option, though they
> offer different data sets in combination or independently, too. Except for
> WURFL the W3C standard is alive and makes the biggest market share across
> DeviceAtlas, DetectRight or the only relevant Open Source alternatives
> which are either OpenDDR or DeviceMap nowadays.
>
> So it's not about how many clients, we should ideally offer as many
> languages as major commercial vendors if we can. And if there's more than
> one data set (most of these vendors got half a dozen;-) ideally a client
> should allow to configure and select supported data sets. E.g. DeviceMap 1
> or 2,
>
> So it's about DATA, not clients, and if necessary different data sets may
> have different clients, but the better choice would be one to configure for
> the data set and location of your choice.
>
> Werner
>
> On Wed, Apr 1, 2015 at 11:15 PM, Reza Naghibi <rezan@apache.org> wrote:
>
> > I will say this, if PMC members in favor of the polyglot client/data
> > approach can lay out some kind of roadmap, that would be helpful in
> > understanding the path the PMC wishes to take this project. Otherwise,
> the
> > uncertainty around new clients springing up from the dead is just
> > unbearable and totally unacceptable (in my opinion). I think its fair to
> > ask people to explain what their future plans are, right?
> >
> > So if you want... (im looking at you Werner and Bertrand), please lay out
> > what you see as your dev roadmap for the next year(s).
> >
> > Radu, join in too, what are your plans for BrowserMap? Same to you
> Eberhard
> > with .NET? These clients were less of a concern because they were not
> Java,
> > but with 2.0, all of our previous releases will have some kind of new 2.0
> > code.
> >
> > Finally, a question for those who really wish to walk on the wild side...
> > who is driving your client requirements?
> >
> >
> > On Wed, Apr 1, 2015 at 4:30 PM, eberhard speer jr. <seshat@ducis.net>
> > wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > If I understand correctly, I tend towards Reza's view.
> > > I too have been having some misgivings about the direction things are
> > > moving in : clients before data.
> > > Yes, the data is key and that highlights one issue : getting, storing
> > > and maintaining reliable data.
> > > Apart from that, somewhere along the line OpenDDR messed up the Aspect
> > > thing.
> > > Unlike Werner I do not think that's just a question of untangling the
> > > current data. Like Reza -- if I understand correctly -- I think a
> > > "framework" not unlike OMA's UAProfiles, following the W3C standards
> > > is required -- by the way it seems to me that the W3C 'client' is just
> > > an [unfortunate] example of a client implementing the Vocabulary
> > > [Aspect/Attribute] and that the Vocabulary concepts developed are the
> > > meat of the standard, not the client.
> > >
> > > On the .Net client : why try and force Java code and other conventions
> > > and practices on it ?
> > > Why burden it with stuff like log4net when anyone can wrap the minimal
> > > .Net client in anything they like and add logging IF they need it.
> > > I can imagine for debugging [use application log for that : faster,
> > > 'native', no dependencies] a log may be handy but otherwise it's
> > > ballast and dependencies. In the time it takes to log an even the
> > > client can parse, what 10, 100 user-agent strings...
> > >
> > > So, I too await Reza's return -- had to look up "holiday" tho ;)
> > >
> > >
> > > esjr
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v2.0.22 (MingW32)
> > >
> > > iQEcBAEBAgAGBQJVHFV0AAoJEOxywXcFLKYc88oH/A36up91ipM/Rc54nYIpEh0u
> > > Wd0+LjC7pdronUKYU2bOmN6xPSOCg2SpJDnYRjKjebk59w6NxLYPOiKR0aBAV6TG
> > > HWyikxTt8QHlFHDiI9TUBifZWTzXhUmAdnrZWYDi+gtG0zZsoBlwAbjCCSMAkEUR
> > > hZtIUw/1UTyQH+TmnP0T6cnt/i0ZttjdsRR8JJSeQiW+kylxZuLQ6/2JX3F8xM+b
> > > zOJouK4oZJIUuoE1aCodcifHjeRvllg8V8ly63jPqAWWXojRLlBwoFqp2PLUSS4+
> > > NMSVbIG04F/lcaTI+jFGgXT9vYfGIwK5u+OzdyOHAsr8q5w5wDtyTD+qATMgCLg=
> > > =ieOW
> > > -----END PGP SIGNATURE-----
> > >
> > >
> >
>

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