So if I understand this email correctly, you are saying that the legacy ODDR client is superior? Correct? I wholeheartedly disagree. Just from a design perspective, the legacy ODDR client loops thru each pattern, 1 by 1, and then applies the pattern against the user agent string using a complicated set of manipulations and regex transformations [0]. There is no way anyone with a background in algorithms or pattern matching would say this is a superior approach. Sorry, but I don't buy this at all.
Can I make a suggestion? Would you mind stepping down from this project and continuing your work on the legacy client over at the OpenDDR project [1]? In the last few days, you have demonstrated that your only value to this project is blocking any progress towards releasing. Am I wrong? If so, can you please list out what your contribution goals are? If you are blocking already blocking changes to 1.0.2, what will you do when we begin work on 2.0? If im right and if what you are saying below is true, you will be a lot more successful continuing your work over at OppenDDR [1]. [0] http://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/simpleddr/src/main/java/org/apache/devicemap/simpleddr/builder/device/AndroidDeviceBuilder.java?view=markup [1] https://github.com/OpenDDRdotORG/OpenDDR-Java --- From: Werner Keil <[email protected]> To: [email protected]; Reza Naghibi <[email protected]> Sent: Friday, January 2, 2015 3:55 PM Subject: Re: Deleting the legacy ODDR client and related artifacts from SVN Reza, 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"> <list> <value>SGP31\d</value> </list> </device> 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" or 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 http://tomcat.apache.org/whichversion.html. 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 http://tomcat.apache.org/whichversion.html 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. HTH, Werner On Fri, Jan 2, 2015 at 9:10 PM, Reza Naghibi <[email protected] > 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] https://github.com/OpenDDRdotORG/OpenDDR-Java > > From: Werner Keil <[email protected]> > To: [email protected]; Reza Naghibi <[email protected]> > Sent: Friday, January 2, 2015 2:55 PM > Subject: Re: Deleting the legacy ODDR client and related artifacts from > SVN > > -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 > <[email protected] > > 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). > > > > > >
