In my mind, your #2 and #3 are the same. So DeviceMap aside, ngram parsing and matching is just a way to do pattern matching. Regex is just sugar ontop of this technique. If you look at dClass, it takes it to the next level by actually implementing regex syntax in the pattern matching. Regex is a pattern language. Regex only becomes parsing when you apply the grouping and capture syntax. But you can still get by without capture syntax by just extending the pattern matching, its kind of insane, but possible:
https://github.com/TheWeatherChannel/dClass/blob/master/dtrees/browser.dtree So in this sense, regex is just syntax sugar which compiles down into pattern matching, or as you stated, voodoo :) ________________________________ From: eberhard speer jr. <[email protected]> To: "'[email protected]'" <[email protected]> Sent: Friday, August 1, 2014 1:12 AM Subject: Desktops etc -----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-----
