Well from a design point it is much more flexible, folks at W3C in the Working Group (http://www.w3.org/TR/DDR-Simple-API/) were neither stupid (that is what you seem to insist calling them all the time and brushing a W3C standard away as "irrelevant" just because they take decades on average, HTML 5 isn't even final in all aspects, but it took till Oct '14 to get there http://www.w3.org/TR/html5/) to get those specs in a shape where everone agrees.
It applies what Java commonly calls "Service Loader" or (especially Spring did it very similar just look at all the XML files in our Spring examples) Dependency Injection. If you declare a new builder say FirefoxOSBuilder and the right "Spring like" wiring is done in BuilderDataSource and the class exists on the classpath (it doesn't even have to be the same JAR if stronger modularization was desired) it'll automatically be recognized and used. So compared to a blunt force parsing and ignoring all the important meta-information for most devices, sure, the classifier is still immature and has to improve. Same for ignoring updated UA evidence like the version. Some vital suggestions by e.g. Volkan include minor variations of other existing devices, There a sensible update to BuilderDataSource regex with just a few characters will do the trick, while Classifier likely will ignore or mistake the regular expression in BuilderDataSource for a device ID. So there are design aspects that were not taken into consideration and they make it more monolithic and less extensible than the W3C design. We did not design it at W3C but properly implemented it throuch OpenDDR/DeviceMap DDR. The only real drawback they may not have thought of back then was a "random" location for the XML files e.g. from within a remote JAR. However, while Spring has new options to inject via annotations (JSR 330) now, if you use the XML files, I am not aware, even Spring 4 or 5 will offer those XML files like applicationContext.xml to be loaded from a remote URL or even separate JAR either;-) Nor has Java so far introduced a Service Loader mechanism that does not depend on XML or Properties files in a well known folder like META-INF, so W3C DDR implementations are as good or bad as these "Service/DI" solutions in Java. Not something to really blame them. Werner On Fri, Jan 2, 2015 at 10:27 PM, Werner Keil <[email protected]> wrote: > Reza/all, > > See another complete rewrite of an existing Apache project and how they > handled that in SVN: > https://svn.apache.org/repos/asf/logging/log4j > > The Log4J 2 project has its completely new separate folder. While on the > "java" side in theory 2 independent Maven modules don't do harm to each > other (same with the /examples module where both libraries/clients are used > on top of the same data structure) there should be a plan and structure for > data allowing e.g. patches to the 1.x data where necessary while evolving > new 2.x data. > > I guess a separate structure either just for data, code or both is > perfectly fine, but that doesn't mean deleting a working 1.x ready > artifact, no other projects do that see Log4J. > > You keep picking on the mature and well demonstrated (with working > examples) W3C DDR client, but what has been "dormant" since July are both > the C# and VB client, which are unlikely to contain any of the updates or > improvements to Java Client 1.1 or even 1.0.1. If any of these were to be > considered "dormant", it's probalby the .NET projects. > > They released a 1.0 but at least the VB project contains weird folders > like "My Project" and unless a Visual Studio Community Edition is > sufficient, I admit it is not so easy to run them anyway unless you have a > fully licenced Microsoft environment (I don't although I write PowerShell > code at a current client) > > Werner > > > > On Fri, Jan 2, 2015 at 9:55 PM, Werner Keil <[email protected]> wrote: > >> 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). >>> > >>> >>> >>> >>> >> >> >
