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 19:55:07 GMT

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