I'm afraid, you're missing the reality of W3C vs. other adoption by
commercial products and open source projects still around.
Out of

   - DeviceAtlas
   - MaDDR
   - OpenDDR
   - WURFL
   - 52Degrees.mobi

only 2 are not W3C compliant, all others are.
Volantis was, but after the company was sold even a few months before WURFL
was closed down, and then again at the end of 2013 there is no trace of
that product being actively sold.
It was among the most W3C compliant ones, and while some users may have
moved to others (especially the equally complient DeviceAtlas) there are
likely sites in production using its old DDR before it was sold. If they
need to upgrade with a W3C complient alternative it's more or less like
switching from one Java Servlet Container (like Tomcat) to another (like
JBoss, Glassfish,...) while other completely different APIs like WURFL or
your "new" client will force these users to more or less rewrite their
entire application from scratch.

And see GitHub primarily W3C/OpenDDR has been adopted by other Open Source
projects and languages/frameworks from

   - Tapestry/Java
   - Sling/Java
   - Scala
   - PHP
   - Lisp
   - Play!
   - JavaScript
   - C# (you probably know its state or used it as initial contribution, at
   least the one by OpenDDR)

Some may be more mature, others less, but compared to a demo service that
is constantly down and shows
502 Bad Gateway
Most of these seem not less mature or at least make that impression.

You are right not every Apache project may need a demo site or service, but
if we do, it should WORK, otherwise people think it's buggy by the error
message.
Not sure why the Tomcat instance constantly crashes, but it puts a bad
light on the entire project.

On one hand you say "W3C" is not relevant (which if you look at market
share of vendor) and want to dictate that people must use only ONE API that
is not compatible with anything (even WURFL) they may have used before.
They can't use the "live" 1.0.0 data resources with old OpenDDR clients as
is (at least not without large modifications) so your arguments are close
to WURFL by saying use "The one and only API" or go f* yourself if you have
a W3C solution in production for the past decade or more.

Bertrand suggested both, and that leaves the greatest freedom to all sorts
of users. They can take the Java connector they find best against the same
(OpenDDR donated) device data, if they come from any of the 20 or so
projects using W3C DDR or OpenDDR plus 3 of the leading commercial vendors
(one no longer supported it seems) they will likely find the SimpleDDR
better. If they have a new green field application they might give the new
alternate client a try. After all it's like chosing between

   - java.util.Data
   - ICU4J
   - JodaTime
   - ThreeTen
   - Date4J
   - JavaFX Duration
   - java.util.concurrent.TimeUnit
   - ...

All doing exactly the same if you want a "PoJO" storing Date and Time
information. 4 of them alone in Java SE 8 (!)
Did Oracle or OpenJDK "deprecate" or remove any of the 2 existing ones when
they added 2 more? No. They'll leave it up to what developers find best.
Some need to work with legacy code in production, they will stick to
java.util.Date/Calendar (with the same "mutability" problems your "new"
clients got, that's why I was wondering if the "Review" by Apache Mentors
or Architects outside the project wasn't mandatory before we called any
part 1.0 or "Graduated")
Others may use ThreeTen with a fairly complicated but sometimes a bit more
business-friendly paradigm, or new things like Duration or Interval the old
API did not provide.
Those at Eclipse (or Apache Harmony, there it was also the de facto standard
[?]) often stick to ICU4J, despite the fact that ThreeTen author Stephen
Colebourne thinks his new API is more modern. And given ICU was created 10
years ago (ThreeTen/Joda "only" about 7 years back, with major review
cycles in the JCP I also helped Oracle and the EG to harmonize it with the
rest of the JDK[?]) he's partly right, but nobody using ICU4J in a mature
business app will throw it all away and switch to JodaTime or ThreeTen
now...

Instead of trying to please only your egos or maybe a single project think
of a larger community, then you might undestand some of the proposals or
rationales behind offering them a choice of 2 or more APIs. Especially as
the one based on W3C was reviewed and found best in the first place,
otherwise it would not have been an initial contribution to DeviceMap.

For .NET there are often less Open Source alternatives. 52Degrees.mobi are
said to work very well with .NET and even seem to have partnerships with
Microsoft, so you get a trial version or limited device content with some
products like "mobile" editions of VisualStudio, etc. DeviceAtlas has broad
support for almost every major language. WURFL probably has some
rudimentary support, but when it was still Open Source, too, Java and other
languages in the Web were more its focus, so that probably has not changed
for commercial clients who decided to stay with them after the business
model mimicked that of DeviceAtlas more or less...

Cheers,
Werner

On Thu, Jul 10, 2014 at 4:26 PM, eberhard speer jr. <[email protected]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I'm not sure I understand what the "Java and .NET clients are a bit of
> a moving target" refers to.
> With the exception of the recent refactoring of the Loaders with the
> intent to release, the 'core' code has been unchanged in the
> repositories for well over a year.
>
> The .Net version of the API has been running on that core code using
> that data for well over a year too.
>
> And no, the W3C API is not implemented in the service. That API is
> *maybe* a nice pedagogical tool, but *useless* in the 'real' world.
>
> That it runs on a server 'here', I think is irrelevant really.
> It's 'faster' for me and I know of no Apache Infra I can access with
> the same ease for my .Net stuff. I don't mind, I stay within the given
> parameters of the licensing and what the Apache community finds
> acceptable and I'm happy to commit the resources and the result.
> I could 'complain' about 'open source' being .net unfriendly etc
> etc...but that's not the point, and this neither the place nor the
> time, true or not. I do my 'open source' bit, that others go on and on
> about "POM", "Jenkins" etc...sure, I'll take my lumps...
>
> I find the recent Java-'popery' upsetting because it clearly and
> *quite rightly* upset one of the *major* contributors and
> Java-contributor !
>
> I find it doubly upsetting because I now am forced to consider my
> position, upsetting my 'open source' bit and possibly disrupting
> something I care about and contribute to.
>
> Not a happy camper,
>
> esjr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTvqKgAAoJEOxywXcFLKYcEUQH/jplVEqwwVftwxABYq7fmigM
> 4wKgzLgeFkcvisTlFdXygX1u2L3CEFZXkMV2O0pG/34tu88VGLBaK4LuY/+aXqH5
> ELmL808epT1iSyoUaBtewWo8RiS0E8qHobh8NLJCUYdkbHk9qfwPGjVwohFYQich
> A33MDJPNkYXtLj3blMmZiHbi2EWy7gw0zYHqqHhoXUcaaoHChOuJllD5fn9NEKHo
> 1TeImBU2VMmQYkAPGS/clbI4OQXGoOzY+cmO8mgfWRb7gAfnkvv2aKccBRXmBIaQ
> 43Oj0+J0r/B3nE97iz4j0Re27442NS2ZUyRQiGH1Vw0AalJsCt4hPZ5Fs9Zy0Ek=
> =rkoo
> -----END PGP SIGNATURE-----
>

Reply via email to