>>Not sure, if we need to revert We are good on that. I double checked all the code, the classifying clients only look at TwoStepDeviceBuilder and SimpleDeviceBuilder and they ignore the package prefix.
In 1.0.0, I added the more robust android, browser and crawler detection as a patch. I didnt want to cause too much disruption in the core data files on the first release, but I wanted the clients to have the enhanced functionality those patches bring. I made this ticket https://issues.apache.org/jira/browse/DMAP-57 to now move some of those definitions into core data for the next release. What I will likely do is define new builders (BrowserBuilder and CrawlerBuilder) so they shouldn't muck up legacy W3C clients. I will go ahead and break up the desktop browser into their respective operation systems where possible and I will also backfill the new attributes, is_desktop and is_crawler, into the vocabulary. ________________________________ From: Werner Keil <[email protected]> To: "[email protected]" <[email protected]> Sent: Wednesday, July 30, 2014 10:03 AM Subject: Re: Take stock Not sure, if we need to revert it (at least for W3C builders a merge conflict that brought an older package name in was now addressed, the discussion happened largely in JIRA, but Reza also confirmed here it would not break his client) but a good way to use, extend and improve the design and specs by W3C DDR in the data files is something we'd want to improve. I.E. trying to add "features" via the main device data and "vocabulary" files rather than punctual tweaks via the Patch files, which are normally meant for 3rd party custom specific add-ons, e.g. if a particular application wants a fancy property like "has_augmented_reality" we may not currently support in the mainstream data Regarding APIs, it would not hurt if the "New Clients" where available for e.g. Java, C#, VB.NET or other languages let's say PHP or Python feel a bit similar, to the extent each language allows. Having central elements like "Device", "Parser", "Loader" etc. with similar names (if one calls it ILoader because of conventions, well, so be it) would create a familiar feeling among different libraries. I haven't looked much at the WURFL stuff, but its competitors with a longer commercial tradition and strong W3C DDR heritage like DeviceAtlas or DetectRight do this well for selected languages like Java, PHP, Perl or Python, C# or ASP.net. The IoT frency brings along many companies with open or closed business models. Xively as it currently calls itself has a REST/JSON/OAuth based API and language bindings: https://xively.com/dev/libraries/ So within the needs and abilities of DeviceMap could a language specific set of examples or libraries also look like over time. Werner On Wed, Jul 30, 2014 at 9:01 AM, Bertrand Delacretaz <[email protected]> wrote: Hi, > >On Wednesday, July 30, 2014, eberhard speer jr. <[email protected]> wrote: > >> ...I think we all agree a review of the Vocabulary is in order -- for > >> example -- but 'quickly' adding "is_somethingOrOther" to a 'patch' >> file and mentioning it in JIRA does not strike me as proper... > >From the incubation mentor peanut gallery: it is good indeed to discuss >specific things (one per email thread ideally) before implementing them >when they have "big impact", whatever that means. > >And IMO discussing here is better than in jira issues, which are more >fragmented discussions. > >That being said, svn allows for reverting any commit, so it's often better >to ask for forgiveness than permission, for "small" things - assuming >people are willing and able to fully revert things when needed. > >-Bertrand >
