Re: [whatwg] Adding a property to navigator for getting device model

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Oops, misunderstanding all around, sorry about that...
Maybe I can try and explain.

Here's how I would define the various UA-sniffing techniques :

1 - Client-side :
    - Parse : 'read' and interpret 'known' elements in appName,
               appVersion etc and return results.
               Returns only information contained in user-agent string.
    - Query : APIs and DOM

2 - Server-side
    - Parse : same as above, but no API or DOM directly at hand
    - Map   : 'known' elements [model id] in the user-agent string
              allow it to be mapped to a 'record' in a device
              database which returns properties of the identified
              device. 'Real' device.
              Returns information not contained in user-agent string.
    - Probe : inject script that does the client side queries and
              returns the results.

    DeviceMap parses and maps.

- From a strict interpretation [by no means shared by all] it follows
that a desktop in the DeviceMap context is not a device. These
'devices' have become generic, defined by their software rather than
by their hardware specs, so OS, 'browser', rending engine (if any !)
and their versions, contained in the user-agent string, are sufficient
to parse on either side. Here the client appears to have the clear
advantage.


Most devices have a tendency to become 'desktops' in that sense and
mapping or looking up the Model Id in some database at some point no
longer adds anything relevant.

However, this assumes all requests come from 'desktops' in the above
sense.
That may be true in many cases most of the time today, but unless you
do either traffic analyses on that level or server-side detection, you
will never know. And without wanting to get overly dramatic : we do
not want to create a new "Best viewed with 'desktop'" ;-)

I think that's where server-side detection has the clear overall
advantage. It makes no such assumptions and being the 1st the 'see'
the user-agent string and it can 'equip' the client with the right
tools [JS, CSS] for the job, relying on DOM, APIs etc, as well as
handle requests from devices in the strict sense.
Given that the cost server-side is negligible -- currently DeviceMap's
just shy of 100 *micro*-second per user-agent string, with a
microscopic code base and zero dependencies -- and given the added
benefits such as security -- I would go so far as to say : consider
default-denial for the weird stuff -- at some level, server-side is a
must.

I guess that's why we UA-sniffers tend to over-react when there's talk
of the 'our' precious user-agent string.[Sorry !] It's not only
because "sigh, we're so misunderstood" [there, there] but because of
the far reaching consequences even minor changes can have [like IE
dropping it's signature "MSIE"] on some systems.

I hope that clears up a few things.

In the current context, in an ideal world, maybe some way can be found
to make the old X-Wap-Profile idea workable.
[http://www.ducis.net/Miri/UAProfile]
Either the device loading it's own 'UAProfile' [or variant thereof]
and exposing it via an API -- but that's a bit 'rich' I suppose -- or
just a property with a valid URI to a parse-able, standard,
spec-sheet/string/object : JSON for the client and some 'cool' format
for the server [Proto-buf ?].
Remove the RDF from UAProfile and you're halfway there, the technical
part anyway. Surely that can be of some use to the Internet of Things
we hear is around the corner. The Internet of Things, sounds like
"device" to me...

But I repeat, as long the user-agent string continues to contain the
elements mentioned above, sane 'standards' are applied and there is no
fiddling with it's truthiness, I currently see no need to add properties.
Getting an UAProfile-protocol working would be stellar, something I'd
gladly spend time on.

Kind regards,

esjr

PS : please send me you ua-strings, long lists of ua-strings...




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUL55xAAoJEOxywXcFLKYc2DkH/AjbSY1Ui/Bg9IvSforKGMnI
gVA+ZhdXNKTnwGOelwrfl5HYlAjdXYXptTzb5oeTVLAxBphqcI2/tg1eTh3vIop4
9LWxat6nm906NKQTM9eKB66J0M6BkYtqMwArvyfmtOaUIXsiqE1n/UVuB3sOZI0r
wyofzel7KnSZQib01hVsffYN5e+zsrGgo2MLMv6Dw1hFoj2lBIe1Cgce2khMqESb
R5RakA7/jOxwF0ujI188Gyrh0OSwQ8pjwvlx9DHowZOaX93NqUNea4mVHZWYizGN
/vKTcOI61PA0ZTXs25IaOkkjVQwrMF0FJqtW04BGsyE4/Uq0Q8jWI1cfyo9JjEQ=
=36x0
-----END PGP SIGNATURE-----

Received on Saturday, 4 October 2014 07:15:54 UTC