devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <re...@apache.org>
Subject Re: Browser detection / status of version 2
Date Fri, 17 Jul 2015 13:01:59 GMT
Im open to switching the attributes back to camelCase. Thats the more
accepted case for JSON anyway. Remember, nothing is set in stone right now.

A few other points...

I am not too concerned what other projects or products do. DeviceAtlas,
CC/PP, etc. My biggest concern is getting things right for this project.
This means using sound and well practiced logic.

Converting XML to JSON is going to be a handful of lines of scripting code.
Not sure why you are thinking that would be a manual effort.


On Fri, Jul 17, 2015 at 7:45 AM, Werner Keil <werner.keil@gmail.com> wrote:

> Stefan/all,
>
> One good question to ask about a new JSON format are, whether or not to
> abandon the accepted vocabulary or not.
> http://wiki.apache.org/devicemap/AttributeSpec2 suggests some breaches,
> e.g. changing "displayWith" or "displayHeight" to "display_width" and
> "display_height" with no real reason other than putting a "_" there.
> Same with "vendor" vs. "manufacturer".
>
> CC/PP which I investigate for offering Portlet 3 Device Profile support
> backed by repositories like DeviceMap does not seem to define a vocabulary
> as extensive as W3C DDR.
> However, http://www.w3.org/TR/CCPP-struct-vocab/#ProfileAttributes shows
> clearly, where the most common attributes like "displayHeight" are used,
> their names are exactly identical to W3C DDR hence matching current
> DeviceMap data. Not surprising, as most attributes and vocabularies are
> based on groups like OMA and its members who gathered them in the past (and
> some still do)
>
> If you're wondering about DeviceAtlas and their "new" JSON file. The actual
> attributes are optimized and names scrambled into weird numeric UUIDs, but
> the mapping to actual atttibute names
>
>
> ["bisBrowser","bisChecker","bisDownloader","bisFilter","bisRobot","bisSpam","bisFeedReader","bmobileDevice","iid","bmarkup.xhtmlMp11","bmarkup.xhtmlMp12","buriSchemeTel","bhttps","imemoryLimitMarkup","imemoryLimitEmbeddedMedia","imemoryLimitDownload","bmidiMonophonic","bmidiPolyphonic","bamr","bmp3","baac","bqcelp","bmpeg4","b3gpp","b3gpp2","bwmv","bh263Type0InVideo","bh263Type3InVideo","bmpeg4InVideo","bamrInVideo","bawbInVideo","baacInVideo","baacLtpInVideo","bqcelpInVideo","bdrmOmaForwardLock","bdrmOmaCombinedDelivery","bdrmOmaSeparateDelivery","bcsd","bhscsd","bgprs","bedge","bhsdpa","bmarkup.xhtmlMp10","bmarkup.xhtmlBasic10","bimage.Gif87","bimage.Gif89a","bimage.Jpg","bimage.Png","bumts","iusableDisplayWidth","iusableDisplayHeight","smidp","scldc","bjsr30","bjsr139","bjsr37","bjsr118","bosSymbian","bosLinux","bosWindows","bosRim","bosOsx","sosProprietary","sosVersion","sdeveloperPlatform","sdeveloperPlatformVersion","buriSchemeSms","buriSchemeSmsTo","iyearReleased","b3gp.h264.level10","b3gp.h264.level10b","b3gp.h264.level11","b3gp.h264.level12","b3gp.h264.level13","
> b3gp.aac.lc
> ","b3gp.h263","b3gp.amr.nb","b3gp.amr.wb","bmp4.h264.level11","bmp4.h264.level13","
> bmp4.aac.lc
> ","bstream.3gp.h264.level10","bstream.3gp.h264.level10b","bstream.3gp.h264.level11","bstream.3gp.h264.level12","bstream.3gp.h264.level13","
> bstream.3gp.aac.lc
> ","bstream.3gp.h263","bstream.3gp.amr.nb","bstream.3gp.amr.wb","bstream.mp4.h264.level11","bstream.mp4.h264.level13","
> bstream.mp4.aac.lc
> ","bmarkup.wml1","bvCardDownload","btouchScreen","boma","bhttpDirectDownload","bosAndroid","svendor","smodel","idisplayWidth","idisplayHeight","idisplayColorDepth","sinputDevices","smarkupSupport","sstylesheetSupport","simageFormatSupport","sinputModeSupport","bcookieSupport","sversion","sscriptSupport"]
>
> shows clearly, their entire vocabulary in their W3C DDR compatible XML
> format is also used by the JSON files. A Hungarian prefix like "i" for int
> or "s" for String is the only difference.
>
> CC/PP just like W3C DDR also makes clear distinction between
> device/hardware, OS/Software or Browser/UA. This has been there ever since,
> the files dedicated to OS or Browser were just not used as intended and the
> only aspect out of 3 or more was "device".
>
> Nobody with a sane mind and busy workload (as almost everyone here has;-)
> would go and manually enter every single device. Even if a "crowd" effort
> or harvesting it from friendly sites was picked up again, they usually
> gather these based on accepted formats and naming schemes. Either you have
> to translate everything or you lose precious information due to a name
> mismatch.
>
> Werner
>
> On Thu, Jul 9, 2015 at 2:24 PM, Werner Keil <werner.keil@gmail.com> wrote:
>
> > Hi Stefan,
> >
> > Thanks for your reply and a fresh view on both data and clients.
> > Note, the "contrib" section while it may not be technically r/o in SVN
> > there is no more active development. It is more or less an "archived"
> > historical view to some of the original contributions.
> > We further modularized clients in recent months, so
> > clients/1.0/java
> > clients/1.0/java_w3c_simple
> > already tell they belong together.
> > One should have a dependency on the other, even if they may not be
> modules
> > using a common Parent POM at the moment (they should but as long as you
> use
> > the right version of "Classifier" for the W3C "Wrapper" it would work)
> >
> > W3C defined a very bulky test suite (e.g. a class with a 20-30 argument
> > constructor;-O) which I started composing under
> > clients/w3c-ddr/simpleddr/src/test/java
> >
> > Test runner is currently a standalone app, but it seems possible to
> > convert it into an actual JUnit tests, though the test harness does a lot
> > of things at once, and previous results of these tests mainly consist of
> > console or HTML-generated results of a standalone app.
> >
> > On GitHub someone earlier compared OpenDDR to other solutions like
> > 52DegreesMobi:
> > https://github.com/samaxes/ddr-compare
> >
> > It should be possible to run his test at least against the W3C DDR
> > DeviceMap client, too. Would be interesting to see, if data updates
> > improved our results ideally compared to a recent version of other
> products.
> >
> > The 1.0 "Wrapper" I did not try to run against the test harness. It is a
> > partial implementation of the W3C DDR Simple API, so some aspects the
> test
> > expects may not even be there. If all test data is in place for the
> > "classic" W3C DDR client, we could always try both. If an implementation
> > passes all or most of the relevant tests, it may call itself "W3C
> > compliant" against the DDR recommendation.
> >
> > You're more than welcome to help with either client(s) or just contribute
> > to data, whatever you feel most comfortable with.
> > As soon as you got a good enough picture of what's there;-)
> >
> > Werner
> >
> > On Wed, Jul 8, 2015 at 10:27 PM, Stefan Seelmann <
> mail@stefan-seelmann.de>
> > wrote:
> >
> >> Hi Werner,
> >>
> >> many thanks for the detailed explanation.
> >>
> >> I saw BrowserDataSource.xml and OperatingSystemDataSource.xml, but as I
> >> found no "detection" patterns and as the also not loaded by the (Java)
> >> devicemap-client I thought they are not used.
> >>
> >> The project contains lot of pieces, I didn't yet figured out how they
> >> fit together. Initially I just saw and tried the official released Java
> >> device-map client. Now I digged a bit deeper and there are (at least) 4
> >> Java clients in SVN
> >>
> >> clients/1.0/java
> >> clients/1.0/java_w3c_simple
> >> clients/w3c-ddr
> >> contrib/openddr/java
> >>
> >> The one in "clients/w3c-ddr/simpleddr" actually is able to
> >> detect/classify OS and browser including versions. It has lot of
> >> specialized Builders which use regex matching to detect UAs (but e.g.
> >> not Firefox on Windows). Support of an existing W3C API seems noble, but
> >> with its data structructures and namespaces it is a bit cumbersome to
> use.
> >>
> >> On the other hand the one in "clients/1.0/java" just seems to use the
> >> patterns defined in BuilderDataSource.xml, without regex matching. It is
> >> totally simple to use.
> >>
> >> I think it makes sense to define patterns in data files, as different
> >> client implementations can use the same data. Hardcoded parsers are more
> >> difficult to port to other languages/platforms. Regex is quite powerful
> >> but probably slower than simple character matching.
> >>
> >> Sorry for dumping my findings and thoughts. I'm still try to find my way
> >> into the project.
> >>
> >> Kind Regards,
> >> Stefan
> >>
> >>
> >>
> >> On 07/08/2015 10:50 AM, Werner Keil wrote:
> >> > Hello Stefan,
> >> >
> >> > Thanks a lot for your input. You're asking some good and constructive
> >> > questions.
> >> >
> >> > With regards to what devices have a browser, this recent post on the
> >> > DeviceAtlas (clearly the most visible and likely notable commercial
> >> vendor
> >> > in this field) page
> >> > https://deviceatlas.com/blog/which-devices-have-browsers
> >> > It contains devices like XBox or even Samsung Gear, etc.
> >> >
> >> > With regards to dealing with devices and browsers separately, the DDR
> >> > standard and formats has always intended to do so, just look at
> >> >
> >>
> https://svn.apache.org/viewvc/devicemap/trunk/data/1.0/device-data/src/main/resources/devicedata/BrowserDataSource.xml?view=co&revision=1686469&content-type=text%2Fplain
> >> > but this and other XML files are clearly undervalued and barely used
> >> > especially by the "Classifier" family of clients.
> >> >
> >> > Other clients due to their W3C DDR compliant heritage do, but if the
> >> data
> >> > is not maintained there, neither will get you proper results;-|
> >> >
> >> > You're right, that some of the visions around 2.0 can be promising if
> >> > there's enough support by the community. Neither of us can do this
> >> alone,
> >> > and while some projects like this may be smaller than others, a key
> >> reason
> >> > to donate the codebase of OpenDDR here was to increase the community
> >> where
> >> > possible.
> >> >
> >> > Aside from a service-based approach
> >> > https://deviceatlas.com/resources/dynamic-data
> >> > DeviceAtlas also makes it pretty clear, their primary format is JSON
> >> now:
> >> > https://deviceatlas.com/resources/getting-the-data
> >> > while it is safe to assume, other commercial closed-source
> alternatives
> >> > like WURFL still dance around the WURFL.xml even if they may have
> >> stored it
> >> > into some XML DB now, too;-)
> >> >
> >> > An important effort is, to transform existing device information (our
> >> crown
> >> > jewel after all;-) from XML to JSON once the new format or formats are
> >> > defined and agreed on. Whether or not there's also a 2-way conversion,
> >> we
> >> > shall see.
> >> > You can be sure, commercial closed-source vendors like DeviceAtlas
> offer
> >> > this but it's up to the community if we can and want to offer that as
> >> well.
> >> >
> >> > Contributing e.g. via JIRA or (I think you may also self-register for
> >> that)
> >> > the Wiki would be a good start. If you have concrete patches or code
> >> > contributions, attaching them (as patch, diff or "snippet") to a JIRA
> >> > ticket is a good practice to start helping. For some this lead to
> >> becoming
> >> > a full committer, so we'd welcome others to do so if they help on a
> >> regular
> >> > basis.
> >> >
> >> > Thanks and Regards,
> >> >
> >> > Werner
> >> >
> >> > On Wed, Jul 8, 2015 at 12:24 AM, Stefan Seelmann <
> >> mail@stefan-seelmann.de>
> >> > wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> I have the need to classify not only mobile devices, but also desktop
> >> >> browsers and other clients (e.g. email clients) including operating
> >> >> system and versions. The current state of DeviceMap seems not
> suitable
> >> >> for this, for example Firefox and Chrome are just classifed as
> >> >> "desktopDevice".
> >> >>
> >> >> I already tried to add patterns to BuilderDataSourcePatch.xml and
> >> >> DeviceDataSourcePatch.xml. That somehow worked, but if I understand
> the
> >> >> data format correctlry I'd have to create one "device" per
> >> >> OS+version/browser+version, which would result in an insane number
of
> >> >> combinations.
> >> >>
> >> >> Is there a better way to define data using the version 1 device data
> >> >> format to achive my needs?
> >> >>
> >> >>
> >> >> I also browsed the wiki and mailing list archive. The "Device Data
> 2.0"
> >> >> specification looks very promising to me. There seem to be neither
> code
> >> >> nor data (not even prototypes) available. Based on mailing list
> archive
> >> >> I'm even not sure if there is consensus among the developers go for
> >> this
> >> >> new data format.
> >> >>
> >> >> Are there plans within the community to develop the version 2?
> >> >>
> >> >> How can I help (with limited resources...)?
> >> >>
> >> >>
> >> >> Kind Regards,
> >> >> Stefan
> >> >>
> >> >
> >>
> >>
> >
>

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