You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Reza <re...@yahoo.com.INVALID> on 2014/07/30 16:12:47 UTC
Re: builders and data
>>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 <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
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 <bd...@apache.org> wrote:
Hi,
>
>On Wednesday, July 30, 2014, eberhard speer jr. <se...@ducis.net> 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
>
Re: builders and data
Posted by Werner Keil <we...@gmail.com>.
As SimpleDeviceBuilder is only used in the *Patch files right now, it
seemingly takes only these:
<builder class="org.apache.devicemap.simpleddr.builder.device.SimpleDeviceBuilder">
<device id="genericPhone">
<list>
<value>LG</value>
<value>NetFront</value>
<value>Palm</value>
<value>SAMSUNG-SGH</value>
<value>Up.Browser</value>
<value>Windows CE</value>
<value>Windows CE; IEMobile</value>
</list>
</device>
<device id="genericTouchPhone">
<list>
<value>android</value>
<value>blackberry</value>
</list>
</device>
<device id="desktopDevice">
<list>
<value>Mozilla/4.0</value>
<value>Mozilla/5.0 .compatible</value>
<value>Mozilla/5.0 .Windows</value>
<value>Mozilla/5.0 .Macintosh</value>
<value>Mozilla/5.0 .X11</value>
<value>Mozilla/5.0 .Ubuntu</value>
<value>Opera</value>
<value>Safari</value>
<value>Chrome</value>
<value>Konqueror</value>
</list>
</device>
</builder>
and a somewhat longer list in the BuilderDataSourcePatch.xml file also
under "Simple".
Above list like "android, blackberry" (that is not the only place, but one
especially if the parser looks at just a subset of the DDR definitions)
probably needs additional values, if FirefoxOS shall work, aside from a
"genericFirefoxOS" or similar root entry. Like in other cases, the top
level device classes may be OS independent, then we might do without a
"genericFirefox*" but need pointers to the new OS similar to Android or
Apple at the moment.
Of course "desktopDevice" may be anything from Windows to Apple/Mac or
ChromeOS (have we ever tested that btw, some vendors seem to sell it already
[?]) which in addition ot Android may at least appear on a tablet or similar
"factor" device, too (there are others, the UA site contains a limited
number of devices like "XBox", "PlayStation" or "Wii", one may call that
"genericConsole" and don't forget the "Wearable" trend, I saw thoug clunky
and ugly smart watches in Nürnberg with a real browser, too[?])
Werner
On Wed, Jul 30, 2014 at 4:12 PM, Reza <re...@yahoo.com.invalid>
wrote:
> >>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 <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> 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 <
> bdelacretaz@apache.org> wrote:
>
> Hi,
> >
> >On Wednesday, July 30, 2014, eberhard speer jr. <se...@ducis.net> 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
> >