cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Better and Better and RT
Date Thu, 09 Nov 2000 23:03:42 GMT
On Thu, 9 Nov 2000 16:26:14 -0500, "Berin Loritsch" 
<> wrote:

> ----- Original Message ----- 
> From: "Donald Ball" <>
> To: <>
> Sent: Thursday, November 09, 2000 2:29 PM
> Subject: Re: Better and Better and RT
> > On Sat, 4 Nov 2000, Ross Burton wrote:
> > 
> > > I have plans to write both of these.  I'm currently finishing a spec for
> > > BrowserCapabilitySelector which will include Accepts as a parameter, and
> > > IIRC a ParameterMatcher was posted recently which might be able to be
> > > changed to a selector.
> > 
> > any luck searching for an open database of browsers and their
> > capabilities, or do we still need to write our own? :)
> I believe that is the wrong approach.  HTTP requests are
> accompanied by certain parameters that web servers
> automagically turn into CGI variables and such.  I could
> have Netscape 4.7x with the Adobe SVG plugin, and can
> accept SVG files.  However, the person in the next office
> could have the same browser but no plugin.  Beyond that,
> Netscape 4.x on Unix can accept gzipped streams while
> Netscape 4.x on Windows and MacIntosh can't.
> Use the variables that the web server gives us, and we
> don't have to have a database of what browser does what.

At least for WML browsers, you need to have such a database anyway, because
there is a lot more information you need to know other than what are the MIME
types accepted by the browser. Things like the number of softkeys, number of
characters on a line, numbers of lines on a device, maximum size of the WML
page accepted by the device and lots of other parameters are not passed in the
HTTP request. Some of the WAP gateways out there, mostly gateways
which are used pretty much in US, do pass some of this information. but not
all. However this is not the case with other WAP gateways, so you need a way to
get this information.

For HTML browsers you probably need to put in the database information on the
various idiosyncrasies of various browsers. Things like frame support,
different levels of JavaScript support etc. Other information needs to be
obtained dynamically from the browser, like Java/JavaScript enabled/disabled,
plugins installed etc. This dynamic information however can supplement the
static information encoded in the browser's capabilities database.

The idea would be to have a static database of capabilities for various
browsers which is supplemented at runtime with dynamic parameters which depend
on the user's preferences and browser installation. The patch I posted solves
the first problem; the second can be added on top of it I think quite easily.

Ovidiu Predescu <> (inside HP's firewall only)

View raw message