cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 16:57:51 GMT
Stefano Mazzocchi wrote:
> 
> Giacomo Pati wrote:
> >
> > Nice work, eh! Here my first comments about your sitemap proposal.
> >
> > Let' s put your sitemap example into CVS as the
> > MOST_COMPLETE_SITEMAP_EXAMPLE_WE_ARE_STILL_WORKING_UPON.
> > The reason is, we have saved it somewhere, it is quite complete as a
> > reference, we can use it as a base for documentation, maybe something
> > like the doc for ants build.xml.
> 
> +1 so we can do versioning on the changes.
> 
> I'll add some comments tomorrow and check it in after removing the
> typos/wordos.

Like you said. It should be selfexplanatory. Write your comments in a
xdocs (or cut and paste out of the "Squaring the sitemap circle"
thread)?

> 
> > 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 :-!

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

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

> 
> > Is "sitemap mounting/cascading" shown in the example sitemap (I've
> > interpreted the mount tag as raw delivery mechanism)
>
> No, like I said in another mail, each mount tag will look for a
> sitemap.xml file (or .sitemap file or whatever we find the best for
> this, I don't care) and, if found, the sitemap is cascaded and merged.
> 
> This allow everyone to have full control on its URI subspace without
> requiring centralized management for everyone that would create a
> bottleneck, expecially on big sites or ISP.> 
> No, like I said in another mail, each mount tag will look for a
> sitemap.xml file (or .sitemap file or whatever we find the best for
> this, I don't care) and, if found, the sitemap is cascaded and merged.
> 
> This allow everyone to have full control on its URI subspace without
> requiring centralized management for everyone that would create a
> bottleneck, expecially on big sites or ISP.

Gotten!

> 
> > > 3) the use of URI for both file and classes locations allows ISP to
> > > provide sitemaps were each sitemap can load classes relative from their
> > > locations without requiring central changes and allowing management
> > > parallelization.
> >
> > Could you further explain (I don't get this)?
> 
> Ok, suppose you have your own juicy component that... let's see, yeah,
> connects to an atomic clock to return the very precise time of the day,
> but your Cocoon is hosted on an ISP and you don't want to
> 
> 1) go thru the process of making the ISP change the sitemap
> 2) make your component available to everyone else (there is no
> restriction on components)
> 
> So you place your nice class inside your directory and you write
> 
>  <component type="atomic-clock" file="classes/atomic-clock.class"/>
> 
> then the Cocoon classloader will know where to locate the class and will
> make it available to your own generators (compiled XSP or your own
> classes).
> 
> Is this clear enough?

Yep!

> > > 8) the use of internal placeholders for components fragments allows
> > > reduction of verbosity when a single tree fragment is reused multiple
> > > times in the sitemap
> >
> > Could you further explain (I don't get this)?
> 
>  Suppose you have
> 
>  <process uri="blah/page1">
>    <generator type="parser" src="./error-pages/restricted.xml"/>
>    <filter type="xslt" src="./stylesheets/general-browser.xsl"/>
>    <serializer type="html" status-code="401"/>
>  </process>
> 
>  <process uri="blah/page2">
>    <generator type="parser" src="./error-pages/restricted.xml"/>
>    <filter type="xslt" src="./stylesheets/general-browser.xsl"/>
>    <serializer type="html" status-code="401"/>
>  </process>
> 
> then you can do
> 
>  <process uri="blah/page1">
>   <resource name="Access refused"/>
>  </process>
> 
>  <process uri="blah/page2">
>   <resource name="Access refused"/>
>  </process>
> 
>  <resource name="Access refused">
>   <generator type="parser" src="./error-pages/restricted.xml"/>
>   <filter type="xslt" src="./stylesheets/general-browser.xsl"/>
>   <serializer type="html" status-code="401"/>
>  </resource>

I've seen it in your example sitemap and it made sense to me but
couldn't link it to your mail

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

> 
> Now, do you see any problems on this area from the sitemap?
> 
> Is there any required functionality that I'm missing?

I still have to grasp it but at the time I don't see any missing.

> 
> Would you be able to clone your latest web-app/web-site using this
> sitemap?

Yes, because they are all very unpretentiously :-)

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message