Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Upayavira" <uv@upaya.co.uk>
To: cocoon-dev@xml.apache.org
Date: Thu, 19 Jun 2003 09:44:02 +0100
MIME-Version: 1.0
Subject: Re: Cocoon resource publishing
Message-ID: <3EF185E2.27728.2C23F592@localhost>
Priority: normal
In-reply-to: <84F0A43A4248CE45B5C0E20F4C40779C6085@naomi.webworks.nl>
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Content-description: Mail message body

Unico,

Replying to your other mail too:

> As you all know, there are currently two ways that Cocoon resources
> are published: either over http or generated on the command line. The
> way we use Cocoon at Hippo seems to be something of a combination of
> these two approaches: an http server running an instance of Cocoon
> functions as a CMS for content editors and explicit publishing
> commands trigger the exportation of resources to a separate live
> server that hosts the actual site.

I had thought of something similar myself too...
 
> I was wondering about whether or not this would be something that is
> genarally useful for Cocoon either as a block or core component set.
> And if so I'd like to know what others think would be the best
> approach to implement this. I currently see several different
> possibilities.

Let me know your ideas. I can immediately think of uses:

1. Have a single Cocoon site (e.g. hosted on a broadband connection, or in=
 a 
companies office) that can publish to 'dumb' web servers. Would be extreme=
ly useful 
for 'poorer' organisations.

2. Have a single Cocoon site that 'syndicates' content to other 'dumb' web=
 servers, by 
sending ready built HTML to them. One of my sites has a list of addresses =
that I 
would like to syndicate to a network of web sites (each paying around =A36=
0pa for 
hosting). Their webmasters are not that technical, so XML pull syndication=
 will be 
beyond most of them, so sending them a new HTML everytime an address chang=
es 
would be absolutely splendid.

> One that we are using at the moment is that of a separate webservice
> that creates custom Environments for each resource to be published and
> passes it to Cocoon to process. The target can be a local filesystem
> or an FTP server. The client interface to this webservice is very
> simple but still rather coarse and experimental: the only parameters
> are the url of the resource to start publishing at and a max-depth
> parameter that is passed to a crawler. The webservice is configured to
> map these urls to target locations so that the same system running
> several different websites can publish these to separate locations.

The new (m3) CocoonBean can itself write to ModifiableSources, so your web=
 service 
wouldn't need to worry about delivering the file. If someone wrote an FTP =
source, 
then all you'd need to say is deliver this url /folder/page.html to this d=
estination 
ftp://u:p@server/folder/, and off it goes. All the web service needs to do=
 is create the 
CocoonBean instance and ask it to generate.

> In order for me to adapt the code so as to make it most useful to
> Cocoon there are several things I would need to decide on. One
> concerns the way clients make publication requests. My current
> thinking is to trigger the publication of resources by specifying 
> some special query parameter after the basic url, similar to the way
> views are currently requested. Another question is how publication
> targets are chosen. One way is to let the client name a pre-configured
> publication target to publish to, another is to indicate this in the
> sitemap, perhaps by providing suplemental information on a pipeline.

Look at the code in the Cocoon bean. The Target class does offer different=
 ways to 
help with the decision as to how the destinations are generated. It can ca=
ter for single 
files being generated, or for whole sites being spidered (even from one ta=
rget).

There's much that could be done on the bean iteself to extend its function=
ality - and 
this would make it more useful to Bean and to CLI users alike.

I'd love to have someone helping me on it!

Regards, Upayavira