devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <>
Subject Re: Deleting the legacy ODDR client and related artifacts from SVN
Date Fri, 02 Jan 2015 20:55:05 GMT

You used the OpenDDR data pretty much as is. There is no "legacy", it is
the W3C compliant implementation that has always worked and produces more
precise results e.g. the real OS version. The approach is different. You'll
find especially some of the most prominent vendors like 52DegreesMobi and
others using a mix of some sort of "repository" and UA interpretation.. The
current classifier lacks the UA based correction all of these handle
whether they follow W3C DDR (like the biggest companies e.g.
DeviceAtlas,... do) or go a different path like WURFL.

Some proposed "refactoring" or new structure would essentially move towards
"Apache WURFL" though I don't care about what they do now, but the big
difference with OpenDDR/DevicMap DDR is WURFL was never W3C compliant
either. Your client(s) including dClass or whatever the others are called
out there may use aspects of the W3C DDR structure but they neither abused
nor perverted them making it impossible to use proper W3C implementations
(both Open Source or commercial, see DeviceAtlas) with this data. Some
"here it is, compile it and do with it what you want" solution is neither
constructive nor useful to anybody.

2 perfectly working examples depend  on the W3C DDR client and they work
with Java 8 which as of now seems  problematic with the Classifier.

What you tried to do for an extra pattern would have to look kind of like
this in BuilderDataSource:
  <device id="SGP311">

This works perfectly fine detecting the UA from that JIRA task regardless
of whether you enter
"Mozilla/5.0 (Linux; Android 4.3; SGP311 Build/10.4.B.0.577)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.102 Safari/537.36"
Mozilla/5.0 (Linux; Android 4.3; SGP312 Build/10.4.B.0.577)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.102 Safari/537.36

While it seems, Classifier only assumes BuilderDataSource <value> entries
as simple deviceIds, they are patterns of the model in the UA.
Like Android or other OS version, fixing the model based on the UA is the
only thing the builder does not do, but it was always meant to recognize
"close enough" patterns based on a Regular expression not just one
particular device ID.

Code in a class like DDRLoader makes hard-wired assumptions, and is rather
monolithic, while the idea behind the W3C DDR Simple implementation is,
that a project where you'd enable OSGi or similar dynamics could even add
new builders at runtime or at least at design time in a separate file, not
one big monolithic class with Hundreds of if clauses.

So from a design perspective, the W3C DDR implementation is better
structured and more maintainable with less "spaghetti code";-)
It certainly uses "Depencency Injection" in a W3C specific way on top of
service interfaces like Builder, Service, Property,... so it doesn't
require Spring, CDI or Guice, also because neither of these (except Spring
Framework, a DI solution largely based on XML, so you'd find a few common
ideas behind both;-) except early versions of Spring Framework were
available between 2004 and 2008.

All major Apache projects have multiple releases in parallel. Tomcat 3 to
8, see
There are 3 parallel Tomcat versions actively developed. Neither of them
considers the other a disruption or competition. Each of them implements
different Specs within the  Java EE umbrella. It's exactly the same with
W3C, and where a future branch of a project was to implement something
else, that is fair, but nobody just deletes all Tomcat versions prior to 8
just for fun. And even the ones
calls "archived" were officially released. That's what the W3C Simple DDR
was ready for ever since. Having Data 1.0.1 available also on MavenCentral
was key, that makes it easier to build each dependent client out of the
box. That (and the glitch in the 1.0 data breaking the W3C client) is why I
did not trigger the release earlier.

There is as little competition or threat by each of the libraries. Due to
its dynamic "service-loader" / DI mechanism just like Spring XML files a
large number of the XML files are important to the W3C DDR client and
changing a class name or adding references in one XML that don't exist in
another may cause errors up to preventing the JVM to start.
Just like Spring with malformed context XML files;-)

Which is why changes that would break this DI mechanism are not feasable on
the W3C compliant 1.x branch of device-data. If a new branch deviates from
that based on redesigning the XML files, that is fine, but it is something
for 2.x And the W3C implementation may not rely on this structute any more.
Users will know and understand that.


On Fri, Jan 2, 2015 at 9:10 PM, Reza Naghibi <
> wrote:

> Werner, I understand. You are against this. However, you did not raise any
> noteworthy points as to why we need to keep the legacy client in SVN. All
> projects release new versions and deprecate old versions, why cant we? The
> client still exists and can be downloaded and maintained at its donation
> source [0]. Otherwise, all im doing is cleaning up the codebase and
> removing dead code. Nothing we have released depends on the legacy client.
> For the sake of moving forward and focusing on the future, im asking that
> we clean up the code base. The legacy client is simply too much of a
> distraction and is already disrupting our data release.
> [0]
>       From: Werner Keil <>
>  To:; Reza Naghibi <>
>  Sent: Friday, January 2, 2015 2:55 PM
>  Subject: Re: Deleting the legacy ODDR client and related artifacts from
> -1
> As Bertrand and others suggested this is an alternate client perfectly
> legitimate and used by clients (your cDate implementation also used OpenDDR
> data first and now the ) among them some of the largest banks.
> You behave as if the DeviceMap project was your "property" not any better
> than the guys who took WURFL out of the Open Source community.
> Under no circumstances you must delete it.
> I don't expect other PMC members to second so you don't do any stupid
> thing.
> The W3C DDR implemementation works perfectly well, just because you don't
> understand it doesn't mean it doesn't work.
> If you did anything stupid to the W3C DDR implementation without a
> qualified majority (I just gave my veto) this violated W3C compatibility,
> hence on behalf of OpenDDR I could only withdraw/delete the entire
> contribution made by OpenDDR. It'll be removed and you'd have to start from
> zero with a "clean slate".
> DDR data in the current structure is MADE for the W3C DDR client. Abusing
> structures in ways you neither understand nor do they work in the
> "Classifier Draft" (hence the broken test or code) is damaging an
> detremental to the project, hence withdrawing all OpenDDR code and data
> would be the only answer to such abuse.
> Do you prefer that?
> On Fri, Jan 2, 2015 at 6:58 PM, Reza Naghibi
> <
> > wrote:
> > Any objections to deleting the legacy ODDR java client and its related
> > artifacts from SVN? This is purely a code cleanup. Here are my thoughts
> on
> > this matter:
> >
> > -The legacy client was rewritten a year ago and it offers a huge set of
> > improvements. Its simpler, several orders of magnitude faster, more
> > predictable, and it moves all of the device logic from code to data.
> > Basically, its modern. One of the biggest changes is that the legacy ODDR
> > client loops thru every pattern looking for a match, one by one, using a
> > complicated set of heuristics specific to each class of user-agents. This
> > does not scale. The new client is able to check all patterns in parallel
> > using pure pattern matching. This scales extremely well.
> >
> > -The DDR data can no longer evolve to support the legacy client. While
> the
> > 1.0.x releases may work, once 2.0 is released, the legacy client will in
> no
> > way shape or form still work.
> >
> > -The legacy client is distraction. Its taking focus away from moving our
> > current objectives forward. This project, like all projects, must evolve.
> > This means rewriting clients, reformatting data, and basically throwing
> old
> > things away. This is a natural process in any software development
> project.
> > The same considerations must be given to old artifacts in this project.
> > This project must evolve.
> >
> > If there are no objections, I will be removing the legacy artifacts from
> > SVN in 5 days (120 hours).
> >

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