-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I known that some of what follows may be obvious and 'old news' to most of us, but just to be clear, *please* bear with me. When a client makes an HTTP request there are 3 ways to get the client's properties and capabilities : 1) Client probe : if supported, using javascript, query the 'navigator' object and other APIs. You basically 'ask' the client. This will get you a pretty accurate picture of the accessible properties. I say "pretty accurate" because UserAgents have been known to lie. [Yes, I'm looking at you Apple.] 2) DDR : here one or more signature n-grams from the UserAgent string 'map' to a 'static' record-set of properties and values. The properties are separate from the UserAgent and can include properties not available via probe [supported communication protocols for example] or not present, 'encoded' or otherwise, in the ua-string itself. 3) Parse UserAgent : here, usually using heavy regex-voodoo, information is extracted and 'deduced' from the UserAgent string. For example : if you run into "WoW" in an ua-string, you're most likely looking at Windows-on-Windows : a 32-bit UserAgent running on some 64-bit version of Windows, the rest of the string will probably tell you which Windows version. It is *very* important to observe here that although methods 2 and 3 are fundamentally different, DeviceMapClient can do both ! Also, methods 1, 2, 3 may and often will return different results for the same client and mostly with good reason. For example, if method 3 reports browser version 2.5 while method 2 claims it's version 1.0, this does not mean the DDR is wrong. It much more likely means the device's browser was upgraded -- an important fact in itself, by the way. Now, with regard to Desktop. It seems obvious to me that applying method 2 to a Desktop is not meaningful. You can not have a meaningful 'static' record-set with non-fluff/default data for a Device with id "desktop". *But*, the same DeviceMapClient can do 'method 3' and return meaningful values, using the same property names as in method 2 [maybe others too like RenderingEngine]. It's just a question of creating the right resources -- I fully agree with Reza there -- and *not* expecting method 3 to return 'default' or other properties specific to method 2. [that, and extracting the exact version numbers from the ua-string] Main point : let's not force method 3 cases like desktops into the method 2 straight-jacket and end up sending out meaningless 'default' data and properties that do not apply. DeviceMap can do both with ease ! The resources are key ! Finally : I fully expect that with time many method 2 Devices will become method 3 'desktop' cases and that new device types and properties will appear in method 2. esjr -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT2yG6AAoJEOxywXcFLKYckuEIAIjIIrSQSYiccdwt31PypNeV OPMDTJOXdwX7VH4p68nTKPk+jByUeJxaC/KRt5HKgfd/da4qUsAXM0NMZ5gD1Wyt Gzbi6fQ8H3+ejNVSGFtPJcH0Vg8K7axTCc3uYNnA1IL9BqC4NCVZLRgC4PHf5nXa 2dLjXVwVTODXvDkF2sjEOeD0jTa7mYiWizrqAQlfW2LojK9Xw4sEttlffPPspSmU uiXdLfcQgpRjUD9YakinsOpoNnCXpoqVtfQ3DN/B9C94mdXmYf5zycuFAGYeYL6b bTMfoj9YJdawp0kTdMPmuSo8FcU3SNFcj4dl0VGkT3gAJ074psbxd049eeKFkLk= =+GrW -----END PGP SIGNATURE-----
