cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Burton <ros...@lineone.net>
Subject Re: [kinda OT] browser capabilities database
Date Thu, 19 Oct 2000 07:06:58 GMT
On Wed, 18 Oct 2000, Donald Ball wrote:

[snip]

> my next thought was to check the browser's user agent string against a
> capabilities database. unfortunately, i'm not aware of any such database
> that's open and maintained. php has support for a browscap.ini file, but
> they don't maintain it apparantly. you can download one sort of for free
> from a company, cyscape, but it's many months old, incomplete, and had
> some weird license restrictions. cyscape _does_, however have a javabean
> component called browserhawk which can tell you all sorts of information
> about a browser's capabilities, given an HttpServletRequest. pretty nifty,
> works well with all of the browsers i've tried, but it's not open, and
> it's not exactly cheap. (interestingly enough, it comes with an obfuscated
> version of ibm's xml4j parser - hope they licensed it legitimately!)
> 
> i'm kind of torn. on the one hand, it's a great little component and it's
> got a comprehensive database (much better than their free browscap.ini
> file). on the other hand, it boggles my mind that there is no open browser
> capabilities database out there. am i missing one, is there in fact
> something good out there? if not, two questions:
> 
> 1. would anyone be interested in helping start such a database and a set
> of libraries to access it?
> 
> 2. will it be fairly straightforward to use a browser capabilities library
> (browserhawk or something else) to do flow control in the c2 sitemap?
> (e.g. apply this stylesheet if the browser supports DHTML, otherwise apply
> this one)

You must be psychic...  a few days ago I started playing with this
idea.  I started with the easy stuff (browser name, which is a simple
regexp on the userAgent string) but stopped on the more complicated
ability detection until I had more time to think about it. My plan was to
create a C2 Selector which can performs tests such as
"supports(XHTML)", "supports(FRAMES)", or "supports(DHTML)", which can be
trivially used in the sitemap to control pipeline flow.

So:  1) Yes and 2) Yes.

Obviously the database would be stored as a XML file - no point in writing
another parser when we have Xerces available.  Good arguments
against XML accepted though!  Questions remaining: what capabilities do we
keep; and how do we perform the matches.

(btw: I noticed when I first looked at Browserhawk that it can detect
whether the client has disabled Java/JavaScript etc.  How is this done
from the server side using a HttpServletRequest?  I thought that
BrowserHawk was a clientside javascript package because of this)

I think a document similar to this might be a good starting point for the 
database:

<browsers>
 <browser desc="IE4" ua="^Mozilla 4.[0-1]+.* \(MSIE,compatible" name="ie">
  <capability name="javascript">1.2</capability>
  <capability name="frames">yes</capability>
  <capability name="java">1.1</capability>
  ...
 </browser>
 ...
</browsers>

The desc attribute in the browser solely exists for editing the file and
the name attribute is a simple string for grouping browsers for
matching. The magic line is the ua (user agent) attribute, which contains
a regexp for matching a ua to set of capabilities (this example is
probably wrong,but it's not far out IIRC).  As we already have the Jakarta
Regexp library this is easy too.  By using regexps the plague of simple
substring matches (as in Cocoon 1 and the BrowserSelectorFactory in C2) is
avoided - ordering.

The browsecap.ini file supports inheritance of browsers, however I am not
sure if we will need it or not.  In browsecap.ini the matches are peformed
using a cut-down regexp parser - basically supports * and ? only. Because
of this, MSIE 4 and MSIE 4.01 have two seperate entries although they have
identical capabilities.  By using proper regexps this redunancy is
eliminated.  But then again defining the "typical" version 4 product and
inheriting from it for MSIE4, NS4 etc will make entries smaller.  But then
again, also slower.

Well, they were my thoughts anyway.  Felel free to ignore them or
comment upon them (preferably the latter however).

Regards,
Ross


Mime
View raw message