Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: giacomo
Message-ID: <3968CD8D.2E2936D8@pwr.ch>
Date: Sun, 09 Jul 2000 21:07:57 +0200
From: Giacomo Pati <Giacomo.Pati@pwr.ch>
Organization: PWR Organisation & Entwicklung
MIME-Version: 1.0
To: Cocoon dev <cocoon-dev@xml.apache.org>
Subject: Sitemap mount element
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all

Now that we have designed the sitemap in general, let's refine some part
of it. I would like to discuss some details about the mount element in
the sitemap. Let's summarize:

The mount elements purpose is (as stated in the working draft):

	Allows sitemaps to be cascaded and site management 
	workload to be parallelized.

It allows partitioning the URI space Cocoon is in charge of. This also
means, that if you are an ISP or a webmaster of the central webserver of
a company that you can give away sitemap functionality to other
customers/employees. And also grant them the right to give away sitemap
functionality to others which also get the functionality and right to
..., and so on.

And as an example of the usage of the mount element (also stated in the
working draft)

	<map:match pattern="cocoon/*">
	  <map:mount
src="cvs:pserver:anonymous@xml.apache.org://home/cvs/cocoon/xdocs/{1}"/>
	</map:match>

Lets have this a a possible sitemap hierarchy:

	                    root-sitemap
	                          !
	      +-------------------+-------------------+
	sub-sitemap-A       sub-sitemap-B       sub-sitemap-C
	                          !
	      +-------------------+-------------------+
	sub-sitemap-BA      sub-sitemap-BB      sub-sitemap-BC
	                          !
	      +-------------------+-------------------+
	sub-sitemap-BBA    sub-sitemap-BBB     sub-sitemap-BBC

All this has brought me to the conclusion that there must be some
managing functionality to keep all the sitemap instances at one central
place (remember that we have generated, compiled and instatiated the
sitemaps as java objects). Consider what happens if the sitemap-BB gets
changed. It must be regenerated and looses all references to its
sub-sitemaps. So this generation and instantiation must be done by a
central manager and a sitemap has to register itself to a manager and
request all sub-sitemaps it requires from a central manager. This
prevent invalidation of sub-sitemaps if a parent sitemap changes. A
possible way to do this is:

     manager.beginSitemapRegistrations(this);
     sitemap1 = manager.register(this, sitemap1URI);
     sitemap2 = manager.register(this, sitemap2URI);
     sitemap3 = manager.register(this, sitemap3URI);
     manager.endSitemapRegistrations(this);

The best place to do this for a sitemap is at the configuration stage
which happens immediately after instantiation. The manager can eliminate
sitemap instances which aren't referenced (registered) anymore from a
specific sitemap (that why there is a need to signal start and end of
the registration to the manager. 

Now, if you take a look at the mount element example above you see, that
the draft specifies the possibility to reference matches from the match
element. This prevents the sitemap from registering sub-sitemaps during
the configuration stage and has to be done during request processing
stage. IMHO this is too dynamic and I would limit the mout element to
specify a path in its src attribute which has to be hardcoded, not
allowing those references.

Please, let us know what do you think about all this.

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