cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 22:48:08 GMT
Giacomo Pati wrote:

> > > Stefano Mazzocchi wrote:
> > > >
> > > > The following goals were identified as engineering constraints:
> > > >
> > > > 1) minimal verbosity is of maximum importance
> > > > 2) the schema should be sufficiently expressive to allow learning by
> > > > examples
> > > > 3) sitemap authoring should not require assistive tools
> > > > 4) sitemaps must scale along with the site and should not impose growth
> > > > limitation to the site as a whole nor limit its administration with size
> > > > increase.
> > > > 5) sitemaps should contain all the information required to Cocoon to
> > > > generate all the resources that it receives.
> > > > 6) sitemaps should contain information for both dynamic operation as
> > > > well as offline generation
> > > > 7) uri mapping should be powerful enough to allow every possible mapping
> > > > need, even for
> > >
> > > 'even for' what?
> > > Did I've seen right, _you_ introduce regex?
> >
> > Yes.
> >
> > I went over mod_rewrite and I must admit there are some parts that make
> > lots of sense, expecially for moving old URI spaces to new ones.... Ross
> > was right, I was wrong.
> >
> > You know, I'm not _always_ right :)
> >
> > And I'll tell you what: if feels good to be wrong. It shows you still
> > have to learn :)
> 
> Yes, but we have even more to do :-!

??? we just received a completely written java regexp engine and it's
not included in Jakarta :)

More to do? sure, just stick another jar in :)

[NOTE: I would have added regexp if we _had_ to write them :) I'm
openminded, but not a total idiot :)]

> > > > 8) basic web-serving functionalities (redirection, error pages,
> > > > authentication) should be provided
> > >
> > > Could't we leave authenticatin to the container (servlet engine/web
> > > server) and concentrate on authorisation? It seems to me your sitemap
> > > example reflects only authorisation, right?
> >
> > Oh, didn't think of that difference.... yeah... sure, I think...
> > welll....
> >
> > I don't have a clear vision on this :( sorry....
> >
> > but you worked on Turbine: you mean let things like turbine do the
> > authentication and use the sitemap just to restrict based on the types
> > of users?
> 
> No, let the user choose out of several possibilities his common
> infrastructure offers (excluding Cocoon). If he uses Cocoon he already
> has a servlet engine and a web server. Servlet engines like Tomcat can
> authenticate in several ways (you can even plug in your own written
> authentication classes) as the 2.2 servlet spec. says so. Web servers
> can also authenticate in several ways. I think you know apache well. 

To be entirely honest, I don't. :/

> You
> can do Basic Authentication so your browser pops up a userid/password
> dialog box which you have to enter. You can even go over SSL and require
> the user to have a valid certificate in the browser to authenticate
> itself. These mechanisms also do some authorisation in the way allowing
> the authenticated user to choose the URL requested or not. But all this
> happens outside the servlet/application. At this point some information
> (userid/password/certificate data) should be passed to the servlet as
> headers so the servlet (here cocoon) can further determine if the
> particular user is granted access to specific data in the URL requested
> (might be that he can see parts of the data but not all). Speaking in
> terms of the sitemap you can only grant on URLs (he may access the URL
> requested or not). Only an XSP page (or some equivalent logic) can
> determine if the user (according to the header data) can access certain
> data the page will offer.

or matchers, right?
 
> > Hey, I'd love to do that.... the problem is I don't have the slightest
> > clue on how to do this! Turbine invoques with Class.forName() and this
> > is not exactly a good thing for us.
> 
> Since Turbine is gone the WebMacro way I've lost somehow interest doing
> things with Turbine (I would much more appreciate doing web apps with
> cocoon, hehe).

Hear, hear :) Interesting...
 
> > > 4. According to <matcher> component and <match> process element,
should
> > > we name the <generator> process element <generate> (and also
> > > <serializer> and <serialize>)?
> >
> > Good point. Didn't think of that one, but sounds like a good idea, would
> > also allow us to separate them for schemas.... yeah, I think they truly
> > are different elements. Anywone else?
> 
> But it doesn't work for the <filter>s!!

I know!!! Suggestions?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message