-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reza,
In reply to you question, my approach to "matching and classifying" is identical to OpenDDR's. My fork of the OpenDDR code -- Miri (http://www.ducis.net/miri) -- only differs from the origial OpenDDR in that it can connect to various different data-sources. Currently the resolver-engine, which is basically the OpenDDR code, can connect to XML, SQL, Redis and flat-files. There are a number of reasons for doing this, some of which will become clear below; mainly depending on the desired functionality of the DDR. I have downloaded your dClass code some time ago. After having dusted off my rusty and in places rather sketchy C and having a good look at it, I'm convinced that of all the DDR solutions I have seen -- and I think I have investigated pretty much all of them in some detail -- dClass is without a doubt the fastest, meanest resolver around. When it comes to taking an incoming web-request's user-agent and resolving it to a device with (some of) it's properties (1) nothing I have seen and tested beats dClass when it comes to speed. However, and this is maybe an issue that should be resolved here : is this the only functional requirement for DeviceMap ? It seems to me that a good versatile DDR should also be useable for traffic analyses (how many Android vs. iOS requests were there, is Fennec 'popular', what's MS's newfangled devices' share, etc) and this is an area where dClass' emphasis on speed leaves it at a serious disadvantage. Having said that, I can imagine a DeviceMap with various operational settings or 'modes' where "live resolver" would follow a code-path involving dClass' approach and "analyzer" would follow a slower more detailed, say OpenDDR approach. On the other hand, while speed is very important, it is basically only relevant when you consider how fast a single incoming request can be 'dealt' with (resolve->route). Unless a DDR implementation depends on an 'external' data-engine like SQL or Redis, the number of incoming request per second has no bearing on speed or performance. For example, in it's current form my OpenDDR fork (like OpenDDR itself could/can), loads all OpenDDR data from a (prepared JSON) flat-file in RAM, on application start-up; each session/request uses (and then disposes) an instance of the resolver engine to do its thing and caches the result for reference throughout the session. As a result, whether there is 1 incoming request per day or say 3,000 per second, the average resolution time will always be around 12 ms, which when viewed in the request's 'timeline' is more than adequate. Another area of functionality I see is : connecting to the 'user'. All solutions fail miserably to connect to their actual intended audience : website makers and operators. I think there are two areas here : implementing a DDR solution, i.e. : inserting routing 'forks' in running sites to route traffic to the appropriate content, and secondly : building content with specific groups of devices in mind. Returning to the 'database' +65,000 of user-agents I can contribute : it is a growing data-set I use to test to see : a) where are the gaps (for example Dalvik and BlackBerry UAs don't score too well) and b) where are the bottlenecks (for example Android using Safari resolves the slowest and unsurprisingly the 'fruits' : Apple's iThingies, the fastest) A subset of this data-set, consists of some 12,000 UAs of 2199 unique devices of which the manufacturer, OEM model name and screen-size are known. Looking forward to our continued debate, Kind Regards, esjr (1) Properties are another area I think deserves some attention : some of the OpenDDR properties appear redundant and there is the question of which properties are relevant to the desired functionality : example : when routing an incoming request to the appropriate content a device's UAProf URL is not really relevant... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ1BQwAAoJEOxywXcFLKYcHcsH/1yRVvMgYSLWuWk/pax3wI7w 5jqJpfTkqJ5z8cm5jD1+HGMoOTe9rcXIV4UJmELgA2nodpz7wcYGC4dWEkVEsNsm jHvetz+kZqbwzy+Tn4hntycIQT6TRqxa0WJCSg2zBQbitHaEOFPolv2QG159zT7Q 2XjCblQZbkAyE5/6b+SKD0r9gITCoy0i/wqE1GMHSmqjFbfPwvikgSH+Rs7oVN3K lHT7PxFcs0hmHbyTJrsiq4qLnh/vooqWRbq2ugG3OBEQBb2fNxLmXSRHX+SIzMDI zYhOSIIRc++Qmkr4H2waMyS+KqpjRz1wqTAVZbMRWdXU9QaRfpd8kPJUgqWCGH8= =S6DC -----END PGP SIGNATURE-----
