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 Thu, 25 May 2000 19:46:30 GMT
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.

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?

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

> 9) sitemaps should not limit Cocoon's intrinsic modular extendibility
> 10) resources must be matched with all possible state variables, not
> only with URI (http parameters, enviornment variables, server
> parameters, time, etc...)
> 11) sitemaps should embed the notion of ┬░semantic resources┬░
> 12) sitemaps should allow raw resources to be found using URI
> identifiers
> 13) sitemaps should be flexible enought to allow a complete web site to
> be built with Cocoon

Agreed.

> 
> As you see, squaring such a circle is _not_ a trivial task.
> 
> I spent two complete days to write a sitemap that embeds all the points
> above. There are some weak points (mainly authentication issues) where I
> need some feedback, but there are _many_ new design patterns that I
> introduced by simply writing the more elegant schema I would like to
> work with.

See above.

> Several important enhacements were introduces:
> 
> 1) the notion of "sitemap mounting" allows sitemaps to scale with size.
> 2) the notion of "sitemap cascading" allows mounted sitemaps to
> "inherit" configurations about used components as well as to declare new
> ones or overrule inherited ones.

Is "sitemap mounting/cascading" shown in the example sitemap (I've
interpreted the mount tag as raw delivery mechanism)

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

> 4) the notion of matching rules is embedded into the schema.
> 5) the notion of components and component typing is embedded into the
> schema.
> 6) the notion of pipeline programmability thru matching components is
> embedded into the schema.
> 7) the use of a special namespace will guarantee evolution capabilities
> of the schema without compromising back compatibility when the schema is
> finalized.
> 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)?

> 9) the notion of "semantic-source" allows special crawling to be
> executed (XLink harvesting as well as RDF indexing)
> 10) the ability to return HTTP status-codes different that 200 was
> embedded into the <serializer> element.
> 11) the notion of attribute-javabean mapping is assumed when dealing
> with the <match> elements.
> 12) the notion of Cocoon2 configuration databinding is assumed for the
> elements when found inside <components>
> 
> It must be noted that the validation rules CANNOT be isolated from the
> semantics of the logic components that perform the operations, for this
> reason the sitemap itself cannot be validated unless at sitemap
> interpretation when loading.
> 
> It must be noted that the matching architecture allows for simple
> authentication as well as very complex authentication schemas, due to
> the pluggability of matchers.

Are you realy meaning authentication not authorisation?

> I must say I'm very proud of this, it was a _very_ hard job to make all
> these fit together, expecially since there is no other software in the
> world that offers the functionality we are offering with this sitemap.

Yes, good job. Looks good, but this is quiet some work to be done!

> 
> Also note that given the ability to mount sitemaps and resources found
> inside jar archives should allow Cocoon to match functionality with
> other systems that are dedicated to web-application generation, but
> still using XML technology as the core.
> 
> Please, take a look and make comments.
> 

Ok, some comments concerninng you example sitemap. 

1. What is the diffrent between ..class="classpath:org... and
...class="classpath://org...?
2. Should we realy introduce regex?
3. If a request-uri matches a mount-uri the request will be satisfied
from the location and basta? Like usual file serving?
4. According to <matcher> component and <match> process element, should
we name the <generator> process element <generate> (and also
<serializer> and <serialize>)?
5. In the example there where two <process> tags with the same uri
(uri=="*"). Is this intentional? 

Some word about authentication. This is quiet a complex area ranging
from so called Basic Authentication to full blown PKI User Certificate
Authentication. I sugest to leave this to the server/container.
Authorisation is the act of giving access to authenticated users, as I
understand it.

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