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 <[email protected]>
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 <[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
> >
