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 23:15:37 GMT
On Thu, Apr 2, 2015 at 12:47 AM, Reza Naghibi <rezan@apache.org> wrote:

> 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.
>
>
It depends on how we manage to broaden participation. Since the graduation
there's been at most 1 person per week, rather month who made any commit.
And aside from BrowserMap (glad to hear something happened there, thanks to
Git and GitHub that's not hard to monitor) only either of us 2, the others
contributed mainly via mailing list (which is also valid, but ideally a few
should also touch code every once in a while)

The roadmap is largely data-driven, we have to cope with new devices and
see "Spartan" or whatever it ends up as a name there will be browser device
variations.




> 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.
>
>
At most we can "freeze" them, as long as an Apache project exists things
don't just get deleted, since there are always existing users or those who
first evaluate carefully. All the Global 100 clients I work with on a
regular basis don't just jump onto a new trend because Google or others
tell them. The majority will also still use Java 7 for a while, some in
Embedded even 6.


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

How many of these actually use DeviceMap in production?
There's the precursor of Client/Classifier on GitHub, so in a sense even
the Java client is a clone/fork or Java rewrite of that C code.


>
> -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.
>
>
See above, if you or others contributed a C client similar to the one on
GitHub or Apache Mobile Filter (also seemingly written in C)
http://www.apachemobilefilter.org/ that would be beneficial. Despite Apache
in the name, that project seems to have nothing to do with Apache
Foundation, but offering DeviceMap as a backend to it could also make it
more appealing to the Apache community.


> -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.
>
>
The IoT will connect devices to the internet even if not all may feature a
traditional browser, but lines are blurring if e.g.your fridge or watch
browses the web or consumes services.

Something clearly worth revisiting are plain is_<somedevice> flags we
inherited from OMA/WAP/WURFL times.
Indicating whether the device has a GSM or other phone feature makes sense,
that is more like the "is_phone" I'd consider useful, not that this would
say anything about the size of the device. If a wristwatch has a phone
built in, then it would also be "is_phone" or whatever we call this
attribute.

Everything else needs a flexible categorization rather than endless is_this
or is_that boolean values.

Werner



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