cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Burton <ros...@lineone.net>
Subject RE: Better and Better and RT
Date Fri, 10 Nov 2000 08:24:56 GMT
On Thu, 9 Nov 2000, Timm, Sean wrote:

> It would be cool if the BrowserCapabilitySelector interacted with something
> that emulated CC/PP.  That way, when CC/PP was finally supported on clients,
> we could jump over to it right away for those that supported it while still
> emulating it for those that didn't.
> 
> Just brainstorming here, so don't flame me too much...:)

Had a good think about this in the shower this morning...  how about this
for a next generation capability selector (it may be totally wrong as I've
just got up)

When a pipeline needs to know about the browser's capabilities, it calls

	<act type="extract-browser-ccpp"/>

Which parses any CC/PP headers in the request object, then looks up the
user-agent in a database and merges in the CC/PP data found there. This
way we can support current browsers by writing all of the metadata in
CC/PP notation, but it is extendable to future browsers too.  Also the
Accepts header is parsed and added to the model. The object containing the
browser profile is added to the object model for the current request, so
it is accessible by the rest of the pipeline.

(Question: how does the WAP capability stuff compare to CC/PP?  Is it is a
subset of CC/PP?)

Then a SelectorFactory can be created which knows of the object added to
the object model, and can react upon it.  Calls such as "supports 
JavaScript 1.2", "supports frames", "accepts image/png" etc are now
trivial examinations of the object.

Comments?  I'm going to try and print out the CC/PP specs today so I can
have a read of them and work this one out.

Ross Burton


Mime
View raw message