Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Marc Portier" <mpo@outerthought.org>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Cocoon apps Web site hosting
Date: Thu, 15 Aug 2002 01:08:54 +0200
Message-ID: <LOEAIGHAMOLFGJLAJOFPIEDADEAA.mpo@outerthought.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <B97ECD0B.10FD5%ovidiu@apache.org>
Importance: Normal

sorry for the late entry.

> -----Original Message-----
> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>
>
> On 8/13/02 3:09 AM, "Ross Gardler" <rgardler@wkwyw.net> wrote:
>
> > Marc Portier wrote:
> >> mmm, to be really honnest: I was even thinking about separate tomcat
> >> instances, to make sure apps could be (completely) restarted
> independant of
> >> each other
> >>
> >> so we end up talking about a cocoon-app-unit of deployment?
> >> (and a deployment interface)
> >> haven't been around long enough, but I was told this has been
> an on and off
> >> issue?
> >> maybe this case gets the itch-level high enough?
> >>
> >> on the other hand: maybe this is a simpel/pragmatic approach:
> >> - apps are put in jars, in the jar sits a subsitemap and all
> other stuff
> >> needed (maybe in predefined COCOON-INF subdirs)
> >> - little process (web trigger?) knows about how to unpack it,
> and deploy it
> >> - probably using /app/ as an automount or something
> >>
> >> there is an issue of overwriting /WEB-INF/ (so
> cross-app-space) classes and
> >> libs, no?
> >> guess we'll just need to manage this (by hand or discipline I
> mean), right?
> >> Maybe it could be (partially) done by means of the cocoon-apps
> cvs repo?
> >>
> >> as for the different versions of cocoon that will need to be
> separate wars,
> >> so we'll end up with some
> >> http://[cocoon-app-site].org/cocoon-[versioncode]/app/[appname]/**
> >
> >
> > This really does make me think we need individual servers, linked
> > through a web-ring, with a central point for reference. The server I am
> > offering is *way* below suitable spec and is not the best connected
> > machine in the world. It will handle a moderate amount of trafic, but a
> > couple of very succesful apps could make it grind to a halt!
>
> Well, the problem is complicated, but I think we can start with simple
> things, without worrying about solving the whole problem initially.

+1

>
> We can assume that everybody runs on the same common version of
> Cocoon, and
> we have a single Cocoon version running on a single Tomcat instance. This
> should satisfy the simple needs, and we can seek solutions for the more
> complex problems as we move along.
>
> The Web ring is the other option which we should consider, and fortunately
> that's something we can start running right away.
>

in fact it would be really neat to have a webring of such servers in the
end.
each of them could then be running a number of apps, the relevant portion of
the docs,
and refer to each other...
all of them could have same skinning, ...

I would go for starting the ring, and gradually find out how we can automate
and streamline the different servers in there.

The newly cvs repository should be driving everything (also the ring-file)
So maybe it makes sense now, when thinking about the organization of the
various apps in there, to reserve space for the mother-of-all-apps-process
(as vagely described) that can be used to easily publish a number of them on
a server.

I know my thoughts are still a bit weary on this, but my work on the
forrestbot made me think about generalizing the applied pattern to this kind
of stuff... I'll be glad to contribute/co-work on something that could do
this

-marc=


> Regards,
> --
> Ovidiu Predescu <ovidiu@apache.org>
> http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache,
> GNU, Emacs...)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org