Good idea!
It is also will be useful try to detect browser/robot type (IE, Opera, Mozilla, etc) and version, xHTML, Javascript support by UA string.

Also noteworthy: http://browsers.garykeith.com/

Seeing Pavel's comment, I'd expect that people want to add more functionality (vendor, version, accept* headers etcetera). Maybe use a plug-in architecture to allow other information to be gathered and queried?

This is useful database with mobile user agents http://wurflpro.com/

Hi, that's my first post over here, so I'm sorry if I got something wrong ^^.
Why using class constants for storing the type of the user agent?
Altough it is a good idea, what if a different useragents are available?
Does the developer should work with the constant TYPE_UNKNOWN? And then what if the past unknown useragent is added to the recognized type of user agents by this class?
Should the developer rewrite her code?

I think in this case using a object to identify the user agent could be better because of further modifications to the class are not needed, instead, she can create new classes that implements a specific interface to add new types of user agents or to customize the recognized user agents.
Something that behaves like the Null Object Pattern or Strategy pattern should do the job very well.
For instance:

In that way also informations about the user agent can be provided!
I know a library that permits to retrieve user agents information, give it a look: http://garetjax.info/projects/browscap/

I hope my comment can be helpful!

Christer, it appears that the community is already providing feedback on this proposal. Is it ready for review? If so, please reparent it and announce on the mailing list.

Thanks.
,Wil

Argh. I already wrote a really awesome implementation of this, but it's proprietary. I can give you some tips, however:

• Pluggable data sources
• Knowing specifics about the browser on the server side is not terribly useful; look at DeviceAtlas and WURFL
• You can't predict every bit of information a user might want to get if they wish to create custom data sources, so your interfaces must be very generalized

Your proposal, as it currently stands, doesn't seem that useful. Capabilities are what users want to know.

Is this proposal dead ? hope not :|

I think this component could be very useful. For example Zend_Session. Cookies are send based on old 'Expires' method - if session time is set to low value and client and server are in different timezones, cookie could expire before it's date. Detecting UA allows You to use 'Max-Age' for modern browsers. You also need to remember to secure this string as it could be everything.

I suggest to use browscap.ini to gather all available information. See:

http://www.php.net/manual/en/function.get-browser.php http://browsers.garykeith.com/downloads.asp

use user-agents.org for distribute the type of user agent and more features.
use the standard xml file for data base of user agent.
but join with Zend_Cache for increase the operation performance.

thank and good luck.

Probably, it can be useful, but I believe it belongs to the Request object.
So, perhaps placing it as Zend_Controller_Request_UserAgent would be a better idea.
Or, even better, you could make it as a plugin, injecting this information on the request object.

Regards

There is an xml file over at http://user-agents.org/ that seems to be pretty up to date. Would it be possible to add this file to Zend Framework and parse it when using the user agent component? There should of course be easy options for caching this information using for instance Zend_Cache as mentioned above.

The xml is about 700KB so it's quite heavy... I guess compiling a separate list internal to Zend Framework is not the way to go. The xml file is also quite fine-grained, and I don't really think we need all that information.

Any ideas?

Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.