The more languages support our data, the better,so anybody should favor a polyglot approach.
Compared to OpenDDR the real world usage and adoption by other projects still makes the Classifier clients pretty young and fairly used. Bertrand can best speak for where he uses the data, but it sounds from what he said about the importance of DDR data as opposed to clients, if he or others at Adobe use it, they probably won't use any of the Java APIs provided with DeviceMap. You'll find more 3rd party repositories wrapping or re-implementing OpenDDR for various languages (from Perl or PHP to Lisp) than DeviceMap is even used on GitHub including BrowserMap mirrors. DetectRight does not have an Open Source device repository, but a fairly polyglot approach to clients for their Web Services: https://github.com/DetectRight However, DetectRight probably has one of the most diverse offerings: http://www.detectright.com/cloud-detection.html W3C Core or W3C + DeviceAtlas are all W3C compliant, so essentially it's similar to DeviceMap's data set. So some of the biggest names in the industry (DeviceAtlas or DetectRight aside from commercial WURFL clearly all have a big market share) rely on the W3C compliant option, though they offer different data sets in combination or independently, too. Except for WURFL the W3C standard is alive and makes the biggest market share across DeviceAtlas, DetectRight or the only relevant Open Source alternatives which are either OpenDDR or DeviceMap nowadays. So it's not about how many clients, we should ideally offer as many languages as major commercial vendors if we can. And if there's more than one data set (most of these vendors got half a dozen;-) ideally a client should allow to configure and select supported data sets. E.g. DeviceMap 1 or 2, So it's about DATA, not clients, and if necessary different data sets may have different clients, but the better choice would be one to configure for the data set and location of your choice. Werner On Wed, Apr 1, 2015 at 11:15 PM, Reza Naghibi <[email protected]> wrote: > I will say this, if PMC members in favor of the polyglot client/data > approach can lay out some kind of roadmap, that would be helpful in > understanding the path the PMC wishes to take this project. Otherwise, the > uncertainty around new clients springing up from the dead is just > unbearable and totally unacceptable (in my opinion). I think its fair to > ask people to explain what their future plans are, right? > > So if you want... (im looking at you Werner and Bertrand), please lay out > what you see as your dev roadmap for the next year(s). > > Radu, join in too, what are your plans for BrowserMap? Same to you Eberhard > with .NET? These clients were less of a concern because they were not Java, > but with 2.0, all of our previous releases will have some kind of new 2.0 > code. > > Finally, a question for those who really wish to walk on the wild side... > who is driving your client requirements? > > > On Wed, Apr 1, 2015 at 4:30 PM, eberhard speer jr. <[email protected]> > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > If I understand correctly, I tend towards Reza's view. > > I too have been having some misgivings about the direction things are > > moving in : clients before data. > > Yes, the data is key and that highlights one issue : getting, storing > > and maintaining reliable data. > > Apart from that, somewhere along the line OpenDDR messed up the Aspect > > thing. > > Unlike Werner I do not think that's just a question of untangling the > > current data. Like Reza -- if I understand correctly -- I think a > > "framework" not unlike OMA's UAProfiles, following the W3C standards > > is required -- by the way it seems to me that the W3C 'client' is just > > an [unfortunate] example of a client implementing the Vocabulary > > [Aspect/Attribute] and that the Vocabulary concepts developed are the > > meat of the standard, not the client. > > > > On the .Net client : why try and force Java code and other conventions > > and practices on it ? > > Why burden it with stuff like log4net when anyone can wrap the minimal > > .Net client in anything they like and add logging IF they need it. > > I can imagine for debugging [use application log for that : faster, > > 'native', no dependencies] a log may be handy but otherwise it's > > ballast and dependencies. In the time it takes to log an even the > > client can parse, what 10, 100 user-agent strings... > > > > So, I too await Reza's return -- had to look up "holiday" tho ;) > > > > > > esjr > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.22 (MingW32) > > > > iQEcBAEBAgAGBQJVHFV0AAoJEOxywXcFLKYc88oH/A36up91ipM/Rc54nYIpEh0u > > Wd0+LjC7pdronUKYU2bOmN6xPSOCg2SpJDnYRjKjebk59w6NxLYPOiKR0aBAV6TG > > HWyikxTt8QHlFHDiI9TUBifZWTzXhUmAdnrZWYDi+gtG0zZsoBlwAbjCCSMAkEUR > > hZtIUw/1UTyQH+TmnP0T6cnt/i0ZttjdsRR8JJSeQiW+kylxZuLQ6/2JX3F8xM+b > > zOJouK4oZJIUuoE1aCodcifHjeRvllg8V8ly63jPqAWWXojRLlBwoFqp2PLUSS4+ > > NMSVbIG04F/lcaTI+jFGgXT9vYfGIwK5u+OzdyOHAsr8q5w5wDtyTD+qATMgCLg= > > =ieOW > > -----END PGP SIGNATURE----- > > > > >
