You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@infoplanning.com> on 2000/11/03 23:19:42 UTC

Better and Better and RT

With the latest CVS of Cocoon2, I noticed that all the
samples work as expected again.  I also noticed that
the plumbing is much quicker as well.  Sitemap generation
is roughly the same, however once generated the rest of
the resources compile 10-20% faster than before.

(I know we aren't worried about performance yet, but it's
good to know it is improving none the less).

I haven't tried dealing with the browser selector.

I envision the following additional selectors to be vital
to any site:

ParameterSelector (select things pased on HTTP parameters)
AcceptsSelector (send PNG to browsers that accept it...)

-----------------------------------------------------------
Imagine the following scenario:

A small company wants something that will grow with there
needs.  Most graphic artists build static HTML files and
incorporate tons of graphics that include text in there
(cardinal sin, but reality nonetheless).  The small company
decides to use Cocoon because of its manageability--in the
beginning it will be one or two people managing the site,
but they don't want to be limited later on.

All the graphics are described as SVG so that the text in
the graphics are not hardcoded for eternity.  Because of
legal issues with GIF files, the company wants to serialize
the images in the following priority: SVG, PNG, JPEG.  Also
because this is a conscientious company, they want to
serialize everything with a compressed stream if the
browser supports it.

Because the company supplies a personalized portal for its
community, they want to offer several themes for their
customer's viewing pleasure.  That means that once the user
is authenticated they can be given a different theme based
on their preferences.
-----------------------------------------------------------
What it would take to accomplish the afforementioned
scenario:

Ability to detect what the browser accepts--the differences
between Netscape and IE are workable, but different
versions of the browsers can accept different things. CGI
(and consequently servlets) have a parameter that
enumerates the mime-types that the browser can accept--this
goes a long way beyond Netscape vs. IE and version.

Also, we need the ability to check and set GET, POST, and
cookie parameters in the sitemap to select the proper
resources (transformers, et al).  This goes beyond simple
session management because we need to know who the authenticated
user is.

Lastly, because most sites are not publish only, some
form of database connectivity has to be in the sitemap--unless
you manage the parameters in the logicsheets.

---------------------------------------
If you lust for Ham and Eggs, you have
committed breakfast in your heart
already.   -- C. S. Lewis


Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and Betterand RT)

Posted by Raphael Luta <lu...@networks.vivendi.net>.
Giacomo Pati wrote:
> 
> Marcus Crafter wrote:
> >
> > On Thu, 9 Nov 2000, Giacomo Pati wrote:
> >
> > > The concept of a Matcher is much more general. You can easily write a
> > > Matcher that matches "high load on the servel" or alike.
> >
> >         *nod*.. sounds good.
> >
> > > How about his:
> > >
> > >    <select type="paramselector">
> > >      <when test="myparameter = on">
> > >        ...
> > >      </when>
> > >      <when test="yourparameter = on">
> > >        ...
> > >      </when>
> > >      <otherwise>
> > >        ...
> > >      </otherwise>
> > >    </select>
> >
> >         Excellent idea. I'm putting it together at the moment. Note for the
> >         above example to work, we'll need to add = to the call to 'translate' in
> >         sitemap.xsl (when 'generate-name' is called, otherwise the = sign is
> >         added to the generated class variable name causing a compiler error).
> 
> Oh, yes of course, I didn't think of. Maybe it's better to get rid of
> trying to derivate names from the pattern and generate pure names with
> generate-id().
> 
> >         I also though about implementing 'greater than' and 'less than'
> >         operators too. Over time I would like to expand the set of operators
> >         to include many varied tests. ie:
> 
> Why not. But keep in mind your operators are used by admin people not by
> programmers (and with admin people i don't meant sys admins :). So
> please keep it as simple and understandable as possible.
> 
> You can use an "is" instead of "=" (good old COBOL is comming back :])
> 

I'd rather have UNIX shell like operators name (my own background ;) )
eq for equal
ne for not equal
lt for lower than
gt for greater than
le for lower or equal
...

This avoids the use of restricted characters, covers all the needed operators
and is pretty intuitive for any English speaker or UNIX shell user.

--
Raphaƫl Luta - luta.raphael@networks.vivendi.net

Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and Betterand RT)

Posted by Marcus Crafter <cr...@dresdnerbank.de>.
Hi All,

On Tue, 14 Nov 2000, Marcus Crafter wrote:

> On Mon, 13 Nov 2000, Marcus Crafter wrote:
> 
> > 	Programmer style      Quasi-English style
> > 	-----------------------------------
> > 	==                    eq
> > 	!=                    ne
> > 	<                     lt
> > 	>                     gt
> > 	<=                    le
> > 	>=                    ge
> > 	&&                    and
> > 	||                    or
> > 	!                     not

	Just to keep everyone updated - the selectors are coming along well, I
	had to put out some other fires in the meantime which caused a little
	delay, but I'll have something posted to the list in the next few days.

	Looking forward to everyones comments,

	Cheers,

	Marcus

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:           After Hours    : +49 69 49086750


Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and Betterand RT)

Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Mon, 13 Nov 2000, Marcus Crafter wrote:

> On Sun, 12 Nov 2000, Giacomo Pati wrote:
> 
> > Marcus Crafter wrote:
> > > 
> 	I thought about the following operator set:
> 
> 	Programmer style      Quasi-English style
> 	-----------------------------------
> 	==                    eq
> 	!=                    ne
> 	<                     lt
> 	>                     gt
> 	<=                    le
> 	>=                    ge
> 	&&                    and
> 	||                    or
> 	!                     not
> 
> 	and even for the perl dudes:
> 
> 	=~                    matches (?)

	After thinking about it last night, perhaps this last one should be
	covered by a 'matcher' and not a 'selector' ? What I was aiming for
	was a way to be able to save people needing to write '.. or ... or
	.. or .. or .. or', etc. Regular expressions seemed natural enough.

	I'll can implement the others first, and after a bit of usage we can
	see if the last one makes sense as a selector test case ?

	Comments anyone ?

	Cheers,

	Marcus

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:           After Hours    : +49 69 49086750


Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and Betterand RT)

Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Sun, 12 Nov 2000, Giacomo Pati wrote:

> Marcus Crafter wrote:
> > 
> > On Thu, 9 Nov 2000, Giacomo Pati wrote:
> 
> Maybe it's better to get rid of trying to derive names from the pattern
> and generate pure names with generate-id().

	Might be better solution. With generate-id(.) we're guaranteed of
	getting unique variables anyway.

> >         I also though about implementing 'greater than' and 'less than'
> >         operators too. Over time I would like to expand the set of operators
> >         to include many varied tests. ie:
> 
> Why not. But keep in mind your operators are used by admin people not by
> programmers (and with admin people i don't meant sys admins :). So
> please keep it as simple and understandable as possible.
> 
> You can use an "is" instead of "=" (good old COBOL is comming back :])

	I understand, although as a developer I tend to like 'eq' instead of
	'is' like Raphael suggested. What do you think ?

	I see a lot of power in creating a boolean logic evaluation engine
	which could be used from a parameter selector, a session selector, a
	context selector, etc, in fact any kind of selector that can provide
	a context to operate in (ie. lookup between variable names and values)
	and a string to evaluate. It would provide for a lot of flexibility in
	the sitemap.

	I'm itching to write such a thing, even if it is a little overkill! :-)

	We could please both developers and admins with the operator names ?

	I thought about the following operator set:

	Programmer style      Quasi-English style
	-----------------------------------
	==                    eq
	!=                    ne
	<                     lt
	>                     gt
	<=                    le
	>=                    ge
	&&                    and
	||                    or
	!                     not

	and even for the perl dudes:

	=~                    matches (?)

	with the ability to nest expressions using parentheses ().

	Any others that I'm missing ?

	Implementation wise, my intention was to base the logic evaluator on
	the Interpreter and Composite patterns, perhaps in combination with
	the Visitor and Flyweight patterns where appropriate.

	I thought about also using jlex/cups to build up the logics AST easily.

	Any suggestions, I'd be interested in peoples comments ?

	Cheers,

	Marcus
-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:           After Hours    : +49 69 49086750



Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and Betterand RT)

Posted by Giacomo Pati <gi...@apache.org>.
Marcus Crafter wrote:
> 
> On Thu, 9 Nov 2000, Giacomo Pati wrote:
> 
> > The concept of a Matcher is much more general. You can easily write a
> > Matcher that matches "high load on the servel" or alike.
> 
>         *nod*.. sounds good.
> 
> > How about his:
> >
> >    <select type="paramselector">
> >      <when test="myparameter = on">
> >        ...
> >      </when>
> >      <when test="yourparameter = on">
> >        ...
> >      </when>
> >      <otherwise>
> >        ...
> >      </otherwise>
> >    </select>
> 
>         Excellent idea. I'm putting it together at the moment. Note for the
>         above example to work, we'll need to add = to the call to 'translate' in
>         sitemap.xsl (when 'generate-name' is called, otherwise the = sign is
>         added to the generated class variable name causing a compiler error).

Oh, yes of course, I didn't think of. Maybe it's better to get rid of
trying to derivate names from the pattern and generate pure names with
generate-id().

>         I also though about implementing 'greater than' and 'less than'
>         operators too. Over time I would like to expand the set of operators
>         to include many varied tests. ie:

Why not. But keep in mind your operators are used by admin people not by
programmers (and with admin people i don't meant sys admins :). So
please keep it as simple and understandable as possible.

You can use an "is" instead of "=" (good old COBOL is comming back :])

>         <when test="yourparameter > 30">
>                 ...
>         </when>
> 
>         However there is a problem in sitemap.xsl here. The translate method
>         can turn the < and > symbols into _ symbols which is fine, but the
>         call to 'generate-id()' will give the same id for both generated class
>         variables (because generate-id() is called with .. as a parameter).

Yes, see above.

>         This means the 2 variables can have the same name (eg. if you use <
>         or > in 2 equal leveled when statements).

Yup.

>         I've changed the call to generate-id() to use . (ie. the current node,
>         instead of its parent) to fix this problem - why was it
>         using .. anyway ? Have I possible broken something else ?

I wanted to have the same id based on the <select> element and not on
the <when> or <otherwise>. But yes, anyway, I'll have to change the hole
name generation stuff.

>         I've attached a patch with the changes.

Thanks, it's a workaround for now.

Giacomo

[C2 & patch] Re: Matchers and Selectors (was Re: Better and Better and RT)

Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Thu, 9 Nov 2000, Giacomo Pati wrote:

> The concept of a Matcher is much more general. You can easily write a
> Matcher that matches "high load on the servel" or alike.

	*nod*.. sounds good.

> How about his:
> 
>    <select type="paramselector">
>      <when test="myparameter = on">
>        ...
>      </when>
>      <when test="yourparameter = on">
>        ...
>      </when>
>      <otherwise>
>        ...
>      </otherwise>
>    </select>

	Excellent idea. I'm putting it together at the moment. Note for the
	above example to work, we'll need to add = to the call to 'translate' in
	sitemap.xsl (when 'generate-name' is called, otherwise the = sign is
	added to the generated class variable name causing a compiler error).

	I also though about implementing 'greater than' and 'less than'
	operators too. Over time I would like to expand the set of operators
	to include many varied tests. ie:

	<when test="yourparameter > 30">
		...
	</when>

	However there is a problem in sitemap.xsl here. The translate method
	can turn the < and > symbols into _ symbols which is fine, but the
	call to 'generate-id()' will give the same id for both generated class
	variables (because generate-id() is called with .. as a parameter).

	This means the 2 variables can have the same name (eg. if you use <
	or > in 2 equal leveled when statements).
	
	I've changed the call to generate-id() to use . (ie. the current node,
	instead of its parent) to fix this problem - why was it
	using .. anyway ? Have I possible broken something else ?

	I've attached a patch with the changes.
	
	I'll send in the selector as soon as I have something up and working.

> I hope my examples will help you understand the generality of those
> components :)

	Sure have. Thanks :-)

	Cheers,

	M.

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:           After Hours    : +49 69 49086750


Re: Matchers and Selectors (was Re: Better and Better and RT)

Posted by Giacomo Pati <gi...@apache.ch>.
Marcus Crafter wrote:
> 
> Hi Giacomo,
> 
> On Sun, 5 Nov 2000, Giacomo Pati wrote:
> 
> > Ross Burton wrote:
> > >
> > > Berin Loritsch wrote:
> > > >
> > > > I envision the following additional selectors to be vital
> > > > to any site:
> > > >
> > > > ParameterSelector (select things pased on HTTP parameters)
> > > > AcceptsSelector (send PNG to browsers that accept it...)
> >
> > Take into account that a Selector chooses between multiple possibilities
> > (and a default one if neither choosen) whereas a Matcher returns a List
> > (or maybe we should change that to a Map) of values you can use for
> > substitution in src attributes of Generators and Transformers. I can
> > imaging to have a Matcher that select values out of the environment
> > objects (Request/Response/Session/Context) and a corresponsing Selector
> > which chooses some component to generate the view expected. This way you
> > can still refer to the values the Matcher has evaluated.
> >
> >   <match type="uri" pattern="myuri">
> >     <match type="value-extractor" pattern="unused">    <-----+
> >       <select type="value-selector">                         !
> >         <when test="first">                                  !
> >           <generate type="file" src="mydir/first/{value}/> --+
> >         </when>
> >         ...
> >       </select>
> >     </match>
> >   </match>
> >
> > I really think that we must think in terms of "team play" between
> > components. What do you think about that?
> 
>         I like the idea of having the selector working with the matcher. But I
>         think I'm getting myself confused between the uses of matchers and
>         selectors. :-(
> 
>         My understanding is that a 'matcher' is used to match something
>         against the current request and a specific parameter passed to the
>         matcher. 

The concept of a Matcher is much more general. You can easily write a
Matcher that matches "high load on the servel" or alike.

> 'Selectors' on the other hand are used to test the current
>         request for particular values.

Even here, think of a Selector based on the time of day.

   <select type="daytime-selector">
     <when test="on">
       ...
     </when>
     <when test="noon">
       ...
     </when>
     <when test="afternoon">
       ...
     </when>
     <otherwise>
       ...
     </otherwise>
   </select>

> 
>         I wrote the RequestParamMatcherFactory which I posted a couple of days
>         back, and are now writing a ParameterSelectorFactory - what i want to
>         do is to be able to tell the selector which request parameter it
>         should be testing - but from what I can see, the selector interface
>         doesn't support parameters like matchers do ?
> 
>         For example:
> 
>         <select type="paramselector" param="myparameter">
>           <when test="on">
>             ...
>           </when>
>         </select>
> 
>         Where 'myparameter' is the what should be passed to
>         request.getParameter(); in the generated paramselector code.
> 
>         How can something like this be implemented ? Selectors seem to be
>         designed to use a predefined parameter to select a value from a
>         defined set. What if we want to vary that parameter ?

How about his:

   <select type="paramselector">
     <when test="myparameter = on">
       ...
     </when>
     <when test="yourparameter = on">
       ...
     </when>
     <otherwise>
       ...
     </otherwise>
   </select>

>         I could set all of the 'param's in the declaration of the selector in
>         the selection section of the sitemap (hows that for a tounge
>         twister!), but then there's problems if 2 or more request parameters
>         are used at the same time.
> 
>         Any ideas ? or have I totally misunderstood everything! :-)

I hope my examples will help you understand the generality of those
components :)

Giacomo

Matchers and Selectors (was Re: Better and Better and RT)

Posted by Marcus Crafter <cr...@dresdnerbank.de>.
Hi Giacomo,

On Sun, 5 Nov 2000, Giacomo Pati wrote:

> Ross Burton wrote:
> > 
> > Berin Loritsch wrote:
> > >
> > > I envision the following additional selectors to be vital
> > > to any site:
> > >
> > > ParameterSelector (select things pased on HTTP parameters)
> > > AcceptsSelector (send PNG to browsers that accept it...)
> 
> Take into account that a Selector chooses between multiple possibilities
> (and a default one if neither choosen) whereas a Matcher returns a List
> (or maybe we should change that to a Map) of values you can use for
> substitution in src attributes of Generators and Transformers. I can
> imaging to have a Matcher that select values out of the environment
> objects (Request/Response/Session/Context) and a corresponsing Selector
> which chooses some component to generate the view expected. This way you
> can still refer to the values the Matcher has evaluated.
> 
>   <match type="uri" pattern="myuri">
>     <match type="value-extractor" pattern="unused">    <-----+
>       <select type="value-selector">                         !
>         <when test="first">                                  !
>           <generate type="file" src="mydir/first/{value}/> --+
>         </when>
>         ...
>       </select>
>     </match>
>   </match>
> 
> I really think that we must think in terms of "team play" between
> components. What do you think about that?

	I like the idea of having the selector working with the matcher. But I
	think I'm getting myself confused between the uses of matchers and
	selectors. :-(

	My understanding is that a 'matcher' is used to match something
	against the current request and a specific parameter passed to the
	matcher. 'Selectors' on the other hand are used to test the current
	request for particular values.

	I wrote the RequestParamMatcherFactory which I posted a couple of days
	back, and are now writing a ParameterSelectorFactory - what i want to
	do is to be able to tell the selector which request parameter it
	should be testing - but from what I can see, the selector interface
	doesn't support parameters like matchers do ?

	For example:

	<select type="paramselector" param="myparameter">
	  <when test="on">
	    ...
	  </when>
	</select>

	Where 'myparameter' is the what should be passed to
	request.getParameter(); in the generated paramselector code.

	How can something like this be implemented ? Selectors seem to be
	designed to use a predefined parameter to select a value from a
	defined set. What if we want to vary that parameter ?
	
	I could set all of the 'param's in the declaration of the selector in
	the selection section of the sitemap (hows that for a tounge
	twister!), but then there's problems if 2 or more request parameters
	are used at the same time.

	Any ideas ? or have I totally misunderstood everything! :-)

	Cheers,

	Marcus
-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:           After Hours    : +49 69 49086750




Re: Better and Better and RT

Posted by Giacomo Pati <gi...@apache.org>.
Ross Burton wrote:
> 
> Berin Loritsch wrote:
> >
> > With the latest CVS of Cocoon2, I noticed that all the
> > samples work as expected again.  I also noticed that
> > the plumbing is much quicker as well.  Sitemap generation
> > is roughly the same, however once generated the rest of
> > the resources compile 10-20% faster than before.
> >
> > (I know we aren't worried about performance yet, but it's
> > good to know it is improving none the less).
> >
> > I haven't tried dealing with the browser selector.
> >
> > I envision the following additional selectors to be vital
> > to any site:
> >
> > ParameterSelector (select things pased on HTTP parameters)
> > AcceptsSelector (send PNG to browsers that accept it...)
> 
> 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.

Take into account that a Selector chooses between multiple possibilities
(and a default one if neither choosen) whereas a Matcher returns a List
(or maybe we should change that to a Map) of values you can use for
substitution in src attributes of Generators and Transformers. I can
imaging to have a Matcher that select values out of the environment
objects (Request/Response/Session/Context) and a corresponsing Selector
which chooses some component to generate the view expected. This way you
can still refer to the values the Matcher has evaluated.

  <match type="uri" pattern="myuri">
    <match type="value-extractor" pattern="unused">    <-----+
      <select type="value-selector">                         !
        <when test="first">                                  !
          <generate type="file" src="mydir/first/{value}/> --+
        </when>
        ...
      </select>
    </match>
  </match>

I really think that we must think in terms of "team play" between
components. What do you think about that?

Giacomo

Re: Better and Better and RT

Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 9 Nov 2000, Berin Loritsch wrote:

> > 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.

it's the wrong approach, but the the right approach doesn't work in the
real world yet. not all of the information sent via the HTTP headers is
knowledge without peeking into a browser capabilities database. there is
information strongly implied by the format of the user-agent string (e.g.
this browser supports DHTML) that's sometimes very useful to know, if only
to guess at proper defaults.

of course it's bad form to constrain a browser based on what you think it
can do, you should always provide ways for the client to override you. and
in the long term, the right approach, namely a richer client capabilities
disclosure protocol, will supercede the hack of browser capabilities
databases, but right now, a hack is better than nothing. i'd like for
there to be an open one. everyone always says that they're sure there's
one out there - but i haven't found one that's complete (say, contains
netscape, explorer, arena, opera, konqueror, lynx, and w3m) and
maintained.

- donald


Re: Better and Better and RT

Posted by Berin Loritsch <bl...@infoplanning.com>.
----- Original Message ----- 
From: "Donald Ball" <ba...@webslingerZ.com>
To: <co...@xml.apache.org>
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.


Re: Better and Better and RT

Posted by Ross Burton <ro...@lineone.net>.
On Thu, 9 Nov 2000, Donald Ball wrote:

> 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've got a browscap.ini file which we could be "inspired" from, and I'm
sure there is a web site somewhere which lists all of the user agent
strings popular browsers use, which will be very usefull for generating
the browser skeletons.

The backend of the selector is working now, all I need to do is implement
the selector factory and I can mail it to the list for comments.

Ross Burton


Re: Better and Better and RT

Posted by Donald Ball <ba...@webslingerZ.com>.
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? :)

- donald


Re: Better and Better and RT

Posted by Ross Burton <ro...@mail.com>.
Berin Loritsch wrote:
> 
> With the latest CVS of Cocoon2, I noticed that all the
> samples work as expected again.  I also noticed that
> the plumbing is much quicker as well.  Sitemap generation
> is roughly the same, however once generated the rest of
> the resources compile 10-20% faster than before.
> 
> (I know we aren't worried about performance yet, but it's
> good to know it is improving none the less).
> 
> I haven't tried dealing with the browser selector.
> 
> I envision the following additional selectors to be vital
> to any site:
> 
> ParameterSelector (select things pased on HTTP parameters)
> AcceptsSelector (send PNG to browsers that accept it...)


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.

Ross Burton