If anyone is interested in what UA belongs to who, I'd suggest going over and visiting Gary Keith's website (www.garykeith.com).
He has been keeping track of UA's for quite some time now.... He also ports them out to the "BROWSCAP.INI" file, used by the Microsofts "Browser Capabilities Component" (BrowsCap.DLL) which is located in the C:\WinNT\System32\InetSrv\ directory. To know more about this, Google these words "MSWC.BrowserType" or Google "ASP Browser Capabilities Component"
Gary religiously keeps this file updated on a weekly basis. [url="http://www.garykeith.com/browsers/version.asp"]View Current BROWSCAP.INI version[/url] There's support for IFrames, WAP devices, etc., etc. and a parent he calls Website Strippers in his files. He also will accept NEW UA's if he doesn't have it already, etc... Have a look at his site. It is quite informative.
TechStud ,
[url="http://www.techstud.com/?MetaSun"]www.TechStud.com[/url]
Database of User Agents
Good day,
This source of information is really good, no doubt about it.
However, what should be clarified, before people are getting excited, is the fact that the so called "Browser Capabilities Component" only reports what the browsers are potentially capable of doing / supporting. It doesn't report the actual status of the browser.
So even if the "Javascript" capability reports as "true", it doesn't mean that Javascript is indeed activated on the client's browser.
So globally, this source of information can be used as a complement to what is already available in MT and should not be considered as a replacement in any way shape or form.
I've been following the updates of that site since early July. I didn't mention anything about it, simply to prevent confusions and false expectations, specially for people who are not really familiar enough with the coding aspect of the MT tool.
Regards.
Database of User Agents
Daniel, you are absolutely correct. I should have stated something to that affect in my original post... my bad. Basically what I was trying to lead to, was that this site is a good source to find out some of those quasi-unknown user agents that show up in our logs.
Would it be better to put all of the (available/known) user agent strings into the database, then have the code search the database for a match, instead of puting it into a function in the main code? That way we could reduce the size of the main body of code a bit!? No?
TechStud ,
[url="http://www.techstud.com/?MetaSun"]www.TechStud.com[/url]
Database of User Agents
Good day,
"...Would it be better to put all of the (available/known) user agent strings into the database..."
Ideally speaking yes, this would be a nice to have. What we have to be carefull with here, is the fact that depending of the content of the site on which MT will be running, the user agent strings may differ a bit, due to the type of potential users that will access the site.
For instance, ASP/VBScript related sites have more IE users, where PHP/MySQL sites have more Unix/Mac OS users, so that would be really difficult to have a list covering all the possibilities.
"...have the code search the database for a match, instead of puting it into a function in the main code..."
That statement smells like "normalization". :D
Indeed you're right, it does a great deal of improvement. Not so much as far as the code is concerned, however a more than substantial gain in the database disk space utilisation. Also, "properly" indexed tables makes the lookup phase a breeze, even with MsAccess (for people who are always scrared of inducing overhead when using indexes).
Knowing that the Browser Type, OS and the Browser brand are all determined via the useragents strings, it make only sense to have an ID field in the PageLog table, that points to the UserAgents table one, which in turn points to the 3 other dependent tables.
This is leading to a situation when 4 fields in PageLog will be reduced to 1, however the creation of 4 tables are required to accomodate the change, but is worthing the job. Naturally, code changes are necessary as well, mainly at the queries level.
More tables, doesn't mean necessarely more disk usage, since after a little while, there will be fewer new entries to put in the UserAgents table.
As far as the OS, BrowerTypes, and Browser names, these tables will remain pretty much static, or at least will very minimal changes and they will have only but a few records.
I'm using the above scenario in my scripts and setup, which explains in part why the DB disk usage still low. I have over 32000 records and the DB is barely 6MB in size.
If people don't know VBScript well enough then they better off stick with the script as is, knowing that Chad mention that this type of optimization will / might be implemented in V2.
Chad mentioned earlier this summer in one of the forums that the expansion of the "Expressions" used to filter the useragents wasn't maintained up to date or expanded because his time was more concentrated on the development aspect of V2. He mentioned that more likely some MT enthousiasts would come up and share their findings.
As far as the enthousiast users are concerned, we can pretty much count them on our fingers. I personnally don't have the required knowledge of the "Expressions", so I'm still stuck with few entries for which one or more caracteristics (Browser Type, OS, Brand), are not yet resolved due to this lack.
I don't have any expertise in that aspect of VBScript/ASP, however I can somehow trade tips and tricks, so that everyone would gain.
Let's face the facts, MT is a great product/tool and Chad is doing a hell of a job at improving it. More adventurous people, like me and few others, are going ahead and adapting/expanding the script capabilities.
We wouldn't spend that kind of time on improvements if at the very base the product wasn't worthing to be looked at.
It has been a good product in the past, and it is only but getting better over the time. It is surely topping quite a few tools of the same category by its simplicity and modularity.
Regards.