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
>

Reply via email to