You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2002/08/08 16:01:03 UTC
[DEAL] Proposal: Inclusion of CocoBlog in scratchpad
Carsten Ziegeler wrote:
> Or sourceforge?
>
> We should not use the cocoon cvs for cocoon-apps, I don't
> now the official "apache policy" on this. It is very good
> to have a cocoon-apps area, but I don't want to give all
> 'cocoon-apps' committers also access to cocoon itself.
> So it must be separated.
Sourceforge is good as a development environment, but it will not give
us the means of *showcasing* Cocoon apps. We will end up with
(hopefully) some portal site, but a miriad of little project sites
around this. I think Cocoon will be served better if we can group all
these applications under one umbrelle.
OK, here's my deal:
I'm dreaming of a Cocoon application development community, comparable
to SF, with CVS, mailinglists, and a Cocoon-app deployment environment.
I've been dreaming about this for the past few weeks and did some
homework. I've been figuring out the costs of hosting such a machine and
securing it sufficiently, and I might even consider to jumpstart this
entirely on our (=outerthought) own budget. No big iron server to start
with, of course, just as CocoDocoWiki is run right now.
Consider it to be CocoKrysalis. Now if other companies are willing to
co-sponsor this, they are welcome. This will cost *real* money.
In terms of opportunity management, it might not be wise to post such
statements knowing I'm going offline in a few hours. But since the
opportunity is there, and we are being confronted with the need for such
an environment, I hope you will give me some time to gather all this in
some plan, and come back to it in a few weeks. I'm dead-serious about this.
Warm regards,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/12/02 11:18 PM, "David Crossley" <cr...@indexgeo.com.au> wrote:
> David Crossley wrote:
>> Ovidiu Predescu wrote:
>>> Ivelin Ivanov wrote:
>>>
>>>> How about a web ring?
>>>
>>> Yes, a Web ring is definitely a good idea.
>>>
>>>> I am about to host a coon apps site myself.
>>>> Since we all might be running on different versions and with different
>>>> ideas
>>>> about our applications, maybe a loosely connected structure is better.
>>>>
>>>> Send me your URLs, I'll link from my web site.
>>>> You can link to mine too:
>>>> cocoonhive.org
>>>
>>> Actually we should have something better than this, so that everybody in the
>>> Web ring is able to see the participants without the link management hassle.
>>
>> We could just modify the existing xdocs/link/hosting.xml
>> We certainly do not want to manage two documents.
>
> Sorry.
> On second thought, we actually do need two separate docs.
> "Cocoon Hosting" the existing one, is for organisations
> offering application infrastructure services to run your
> own Cocoon server. The Web Ring idea is specifically for
> fostering a Cocoon Apps developer community. Am i right?
Yes, that's right!
IMO the file does not have to be written in xdocs, we can use instead a
simple XML format to point to the RSS feeds, which have all the relevant
information. I use a similar idea on my Weblog to aggregate RSS feeds, check
out how it's done at:
http://www.webweavertech.com/ovidiu/weblog/archives/000014.html
> The "put an xml doc in CVS" idea is still relevant.
Yes, the CVS idea is good, although a nicer URL which doesn't depend on the
location of the file in the CVS repository might be better. We can probably
use mod_rewrite on the server side to do the redirection to the real URL, or
we can have a simple cron job which generates the file at the nicer location
in the Web server.
>> The problem with this solution is that Cocoon website is
>> still irregularly updated manually, until Forrest.
>>
>>> We can put the sites participating in the Web ring in an XML file on a
>>> central site. All the participants can then fetch this file every once in a
>>> while, and generate the HTML version of it. Very similar with the RSS stuff
>>> in Weblogs.
>>
>> Great idea. Is it sufficient to just get the file from CVSview?
>> GET
>> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xd
>> ocs/link/hosting.xml?rev=HEAD&content-type=text/xml
>> There is probably a better solution down the track, with
>> Forrest generating it for them.
>>
>> Do we need a table in the hosting.xml that summarises them?
>> --David
--
Ovidiu Predescu <ov...@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
Re: Cocoon apps Web site hosting
Posted by David Crossley <cr...@indexgeo.com.au>.
David Crossley wrote:
> Ovidiu Predescu wrote:
> > Ivelin Ivanov wrote:
> >
> > > How about a web ring?
> >
> > Yes, a Web ring is definitely a good idea.
> >
> > > I am about to host a coon apps site myself.
> > > Since we all might be running on different versions and with different ideas
> > > about our applications, maybe a loosely connected structure is better.
> > >
> > > Send me your URLs, I'll link from my web site.
> > > You can link to mine too:
> > > cocoonhive.org
> >
> > Actually we should have something better than this, so that everybody in the
> > Web ring is able to see the participants without the link management hassle.
>
> We could just modify the existing xdocs/link/hosting.xml
> We certainly do not want to manage two documents.
Sorry.
On second thought, we actually do need two separate docs.
"Cocoon Hosting" the existing one, is for organisations
offering application infrastructure services to run your
own Cocoon server. The Web Ring idea is specifically for
fostering a Cocoon Apps developer community. Am i right?
The "put an xml doc in CVS" idea is still relevant.
--David
> The problem with this solution is that Cocoon website is
> still irregularly updated manually, until Forrest.
>
> > We can put the sites participating in the Web ring in an XML file on a
> > central site. All the participants can then fetch this file every once in a
> > while, and generate the HTML version of it. Very similar with the RSS stuff
> > in Weblogs.
>
> Great idea. Is it sufficient to just get the file from CVSview?
> GET
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xdocs/link/hosting.xml?rev=HEAD&content-type=text/xml
> There is probably a better solution down the track, with
> Forrest generating it for them.
>
> Do we need a table in the hosting.xml that summarises them?
> --David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by David Crossley <cr...@indexgeo.com.au>.
Ovidiu Predescu wrote:
> Ivelin Ivanov wrote:
>
> > How about a web ring?
>
> Yes, a Web ring is definitely a good idea.
>
> > I am about to host a coon apps site myself.
> > Since we all might be running on different versions and with different ideas
> > about our applications, maybe a loosely connected structure is better.
> >
> > Send me your URLs, I'll link from my web site.
> > You can link to mine too:
> > cocoonhive.org
>
> Actually we should have something better than this, so that everybody in the
> Web ring is able to see the participants without the link management hassle.
We could just modify the existing xdocs/link/hosting.xml
We certainly do not want to manage two documents.
The problem with this solution is that Cocoon website is
still irregularly updated manually, until Forrest.
> We can put the sites participating in the Web ring in an XML file on a
> central site. All the participants can then fetch this file every once in a
> while, and generate the HTML version of it. Very similar with the RSS stuff
> in Weblogs.
Great idea. Is it sufficient to just get the file from CVSview?
GET
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/documentation/xdocs/link/hosting.xml?rev=HEAD&content-type=text/xml
There is probably a better solution down the track, with
Forrest generating it for them.
Do we need a table in the hosting.xml that summarises them?
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
Ross,
On 8/13/02 2:48 AM, "Ross Gardler" <rg...@wkwyw.net> wrote:
>> Actually we should have something better than this, so that everybody in the
>> Web ring is able to see the participants without the link management hassle.
>>
>> We can put the sites participating in the Web ring in an XML file on a
>> central site. All the participants can then fetch this file every once in a
>> while, and generate the HTML version of it. Very similar with the RSS stuff
>> in Weblogs.
>
> This would be good eventually, but someone has to write that stuff. How
> about a wiki to get us up and running? I can put a JSP wiki (the same as
> the one on outerthought up for this, although we should wait for Steven
> to come back of holiday before doing anything - I don;t want to "hijack"
> his idea)
I've already implemented this code for my Weblog. The process how this works
is described here:
http://www.webweavertech.com/ovidiu/weblog/archives/000014.html
It is actually a very simple implementation, and by putting the
subscriptions.xml file in CVS as David suggested, we achieve the goal
described above. Each site in the Web ring will then simply pull the file
from CVS over HTTP, and run the procedure mentioned in my Weblog.
Regards,
--
Ovidiu Predescu <ov...@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
Re: Cocoon apps Web site hosting
Posted by Ross Gardler <rg...@wkwyw.net>.
Ovidiu Predescu wrote:
> On 8/11/02 11:37 AM, "Ivelin Ivanov" <iv...@apache.org> wrote:
>
>
>>How about a web ring?
>
>
> Yes, a Web ring is definitely a good idea.
Absolutley!
> Actually we should have something better than this, so that everybody in the
> Web ring is able to see the participants without the link management hassle.
>
> We can put the sites participating in the Web ring in an XML file on a
> central site. All the participants can then fetch this file every once in a
> while, and generate the HTML version of it. Very similar with the RSS stuff
> in Weblogs.
This would be good eventually, but someone has to write that stuff. How
about a wiki to get us up and running? I can put a JSP wiki (the same as
the one on outerthought up for this, although we should wait for Steven
to come back of holiday before doing anything - I don;t want to "hijack"
his idea)
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/11/02 11:37 AM, "Ivelin Ivanov" <iv...@apache.org> wrote:
> How about a web ring?
Yes, a Web ring is definitely a good idea.
> I am about to host a coon apps site myself.
> Since we all might be running on different versions and with different ideas
> about our applications, maybe a loosely connected structure is better.
>
> Send me your URLs, I'll link from my web site.
> You can link to mine too:
> cocoonhive.org
Actually we should have something better than this, so that everybody in the
Web ring is able to see the participants without the link management hassle.
We can put the sites participating in the Web ring in an XML file on a
central site. All the participants can then fetch this file every once in a
while, and generate the HTML version of it. Very similar with the RSS stuff
in Weblogs.
Cheers,
Ovidiu
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ivelin Ivanov <iv...@apache.org>.
How about a web ring?
I am about to host a coon apps site myself.
Since we all might be running on different versions and with different ideas
about our applications, maybe a loosely connected structure is better.
Send me your URLs, I'll link from my web site.
You can link to mine too:
cocoonhive.org
Ivelin
----- Original Message -----
From: "Ovidiu Predescu" <ov...@apache.org>
To: "Steven Noels" <st...@outerthought.org>; <co...@xml.apache.org>
Sent: Sunday, August 11, 2002 12:25 PM
Subject: Cocoon apps Web site hosting
> Steven,
>
> I've already paid money to get an account to an ISP for exactly this type
of
> setup. At that time I was talking to other cocoon developers about setting
> up such a site to showcase Cocoon. Unfortunately, none of us had
sufficient
> spare energy to pull this out and to start working on it. At the moment it
> hosts only the Weblogs of myself and Jeff Turner, and Berin's and us email
> accounts, but it will soon host the Anteater Web site as well.
>
> The vision of this is to have a loosely coupled group of developers, which
> have similar interests and work on similar projects, to share the same
> resources. Long term, I'd like us to become a center of expertise for
other
> companies to hire us, either individually or as a group, to provide
support
> and custom enhancements to these projects.
>
> I'm offering this site to host the Cocoon web site you're talking about,
as
> it shares the same vision I had when I started it. We have 1Gb of
hard-disk
> space available and 10Gb of transfer monthly, which should be plenty for
the
> time being. Unfortunately we have only 1 shell account available, but I
> think we can increase that to three accounts with little additional cost,
> which can then be shared among us.
>
> I already have a CVS repository setup for multiple developers, we can
create
> mailing lists and setup a Cocoon hosting environment for Cocoon apps.
>
> Please let me know if this is something which might interest you.
>
> Regards,
> --
> Ovidiu Predescu <ov...@apache.org>
> http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs...)
>
>
> On 8/8/02 7:01 AM, "Steven Noels" <st...@outerthought.org> wrote:
>
> > Carsten Ziegeler wrote:
> >
> >> Or sourceforge?
> >>
> >> We should not use the cocoon cvs for cocoon-apps, I don't
> >> now the official "apache policy" on this. It is very good
> >> to have a cocoon-apps area, but I don't want to give all
> >> 'cocoon-apps' committers also access to cocoon itself.
> >> So it must be separated.
> >
> > Sourceforge is good as a development environment, but it will not give
> > us the means of *showcasing* Cocoon apps. We will end up with
> > (hopefully) some portal site, but a miriad of little project sites
> > around this. I think Cocoon will be served better if we can group all
> > these applications under one umbrelle.
> >
> > OK, here's my deal:
> >
> > I'm dreaming of a Cocoon application development community, comparable
> > to SF, with CVS, mailinglists, and a Cocoon-app deployment environment.
> > I've been dreaming about this for the past few weeks and did some
> > homework. I've been figuring out the costs of hosting such a machine and
> > securing it sufficiently, and I might even consider to jumpstart this
> > entirely on our (=outerthought) own budget. No big iron server to start
> > with, of course, just as CocoDocoWiki is run right now.
> >
> > Consider it to be CocoKrysalis. Now if other companies are willing to
> > co-sponsor this, they are welcome. This will cost *real* money.
> >
> > In terms of opportunity management, it might not be wise to post such
> > statements knowing I'm going offline in a few hours. But since the
> > opportunity is there, and we are being confronted with the need for such
> > an environment, I hope you will give me some time to gather all this in
> > some plan, and come back to it in a few weeks. I'm dead-serious about
this.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Cocoon apps Web site hosting
Posted by Ross Gardler <rg...@wkwyw.net>.
>>I have already contacted Steven privately offering hosting facilites on
>>my own server, nothing particularly major but it is fairly well
>>connected here in the UK and will handle a moderate amount of traffic
>>without problems. Looks like we can start offering mirrors straight
>>away, if only we had something to mirror!
>
>
> This is great news!
>
> Is this a Unix/Linux box? Can we get shell access to it (over SSH
> preferably)?
Yes (Redhat 7.0). Yes, I have full admin rights over this machine and am
happy to install any software requried (or give someone the karma to do
it as my time is limited)
>
>
>>There are (theoretically) no limits to what we can do with this server
>>as at present it only hosts a dozen static sites. There is plenty of
>>available bandwidth, disk space and processor time available.
>
>
> All right, this is great! Do we need to share the costs of this hosting?
No, it is paid for up until April next year. I would hope to continue
paying for it after that, but of course, nothing is written in stone
apart from it is definetly there until April 2003. This is not really a
commercial server (I do have a half dozen customers on there but that is
only to spread the cost), I use it mostly for my research work since the
University support staff are far too busy to respond quickly to my requests.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/11/02 11:37 AM, "Ross Gardler" <rg...@wkwyw.net> wrote:
> Ovidiu Predescu wrote:
>> Steven,
>> I'm offering this site to host the Cocoon web site you're talking about, as
>> it shares the same vision I had when I started it. We have 1Gb of hard-disk
>> space available and 10Gb of transfer monthly, which should be plenty for the
>> time being. Unfortunately we have only 1 shell account available, but I
>> think we can increase that to three accounts with little additional cost,
>> which can then be shared among us.
>>
>> I already have a CVS repository setup for multiple developers, we can create
>> mailing lists and setup a Cocoon hosting environment for Cocoon apps.
>>
>> Please let me know if this is something which might interest you.
>
> I have already contacted Steven privately offering hosting facilites on
> my own server, nothing particularly major but it is fairly well
> connected here in the UK and will handle a moderate amount of traffic
> without problems. Looks like we can start offering mirrors straight
> away, if only we had something to mirror!
This is great news!
Is this a Unix/Linux box? Can we get shell access to it (over SSH
preferably)?
> There are (theoretically) no limits to what we can do with this server
> as at present it only hosts a dozen static sites. There is plenty of
> available bandwidth, disk space and processor time available.
All right, this is great! Do we need to share the costs of this hosting?
> I am extremely busy for a couple of months but am monitoring this
> discussion with great interest as I was planning on doing something
> similar once my current work is finished. If there is anything I can do
> before becoming fully involved just let me know (this includes setting
> up any facilities required on the server).
--
Ovidiu Predescu <ov...@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
Re: Cocoon apps Web site hosting
Posted by Ross Gardler <rg...@wkwyw.net>.
Ovidiu Predescu wrote:
> Steven,
> I'm offering this site to host the Cocoon web site you're talking about, as
> it shares the same vision I had when I started it. We have 1Gb of hard-disk
> space available and 10Gb of transfer monthly, which should be plenty for the
> time being. Unfortunately we have only 1 shell account available, but I
> think we can increase that to three accounts with little additional cost,
> which can then be shared among us.
>
> I already have a CVS repository setup for multiple developers, we can create
> mailing lists and setup a Cocoon hosting environment for Cocoon apps.
>
> Please let me know if this is something which might interest you.
I have already contacted Steven privately offering hosting facilites on
my own server, nothing particularly major but it is fairly well
connected here in the UK and will handle a moderate amount of traffic
without problems. Looks like we can start offering mirrors straight
away, if only we had something to mirror!
There are (theoretically) no limits to what we can do with this server
as at present it only hosts a dozen static sites. There is plenty of
available bandwidth, disk space and processor time available.
I am extremely busy for a couple of months but am monitoring this
discussion with great interest as I was planning on doing something
similar once my current work is finished. If there is anything I can do
before becoming fully involved just let me know (this includes setting
up any facilities required on the server).
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Michael Wechner <mi...@wyona.org>.
Ugo Cei wrote:
> Ross Gardler wrote:
>
>> I would like to know how many people actually have applications that
>> can be put into this environment. I for one am making noise about this
>> but don;t __have__ anything to put in there yet. I intend to have
>> something but that is __very__ different as you all know ;-) So lets
>> also start a list of the real, working (even if only alpha) apps we have:
>>
>> * BringMeThis -
>> http://www.superlinksoftware.com/cocoon/samples/bringmethis/ - Andrew C.
>
>
> * CocoBlog - http://www.beblogging.com/blog/docs - Ugo Cei
I think a starting point for a list is
http://xml.apache.org/cocoon/link/projects.html
Michael
>
> Ugo
>
>
> ---------------------------------------------------------------------
> 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
Re: Cocoon apps Web site hosting
Posted by Ugo Cei <u....@cbim.it>.
Ross Gardler wrote:
> I would like to know how many people actually have applications that can
> be put into this environment. I for one am making noise about this but
> don;t __have__ anything to put in there yet. I intend to have something
> but that is __very__ different as you all know ;-) So lets also start a
> list of the real, working (even if only alpha) apps we have:
>
> * BringMeThis -
> http://www.superlinksoftware.com/cocoon/samples/bringmethis/ - Andrew C.
* CocoBlog - http://www.beblogging.com/blog/docs - Ugo Cei
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>
> One issue I see, as somebody else noted as well, is that different examples
> will need possibly different versions of Cocoon. We need to manage this
> complexity somehow.
>
>
I recommend getting with Nicola Ken and coming up with a solution using
centipede.. The Cooon-apps module could have a common set of build
fascillities, interactive build and even pull the right version of
things from a common repository. When will all these features be
implemented...They already ARE!
http://www.krysalis.org/centipede
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Justin Fagnani-Bell <ju...@paraliansoftware.com>.
> Yes, Marc, these are the core two things we need to capture.
>
> All projects hosted on the site should look similarly, check out
> MozDev.org
> to see what I'm talking about:
>
> http://www.mozdev.org/projects.html
>
> The second is how to manage the complexity of having multiple Cocoon
> versions (I think we can ignore the servlet container difference for the
> moment, that should not be taken into account IMO). We can have each
> example
> app deployed in its own war file, but with today's Cocoon runtime memory
> size and twenty different applications, 2Gb or RAM will be soon
> insufficient.
Isn't there a way to do this with a custom class-loader? You have a
system classpath and a user classpath. If a class is not in the user
classpath, it's loaded from the system classpath. This way a user only
gets their own Cocoon runtime if they have their own cocoon.jar in their
lib directory. I'm not completely sure, but I think my hosting company
(which has Cocoon support) does this, but then again my site isn't the
most reliable in the world.
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/14/02 4:08 PM, "Marc Portier" <mp...@outerthought.org> wrote:
> sorry for the late entry.
No problem. We are still talking about this stuff.
>> 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
Yes, this is what I was trying to convey too. We need to define this meta
application, which is used to create the Web site of the other applications.
We need to identify what are the basic needs for such a Web site and its
layout. Some skins for this layout would also be good, so that an
application's Web site can differentiate its look from others.
Regards,
--
Ovidiu Predescu <ov...@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
RE: Cocoon apps Web site hosting
Posted by Marc Portier <mp...@outerthought.org>.
sorry for the late entry.
> -----Original Message-----
> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>
>
> On 8/13/02 3:09 AM, "Ross Gardler" <rg...@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 <ov...@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
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/13/02 3:09 AM, "Ross Gardler" <rg...@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.
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.
Regards,
--
Ovidiu Predescu <ov...@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
Re: Cocoon apps Web site hosting
Posted by Ross Gardler <rg...@wkwyw.net>.
Marc Portier wrote:
>>All projects hosted on the site should look similarly, check out
>>MozDev.org
>
>
> forrest skins should make this snap
> and I would consider it good practice for all projects to think about being
> skinned
Yes, there are two skins actively supported at the moment. The Forrest
one (http://www.krysalis.org/forrest) and to a lesser extent the
Krysalis one (http://www.krysalis.org, also used by Avalon I believe).
There could be a thrid but it would seem to be a waste of energy.
The forrest one would make us look like an Apache site, not a bad thing.
The krysalis one would give us the opportunity to leverage some of the
efforts Nicola has already put in to setting up a "pre apache"
community, although this is not focussing on Cocoon alone.
>>The second is how to manage the complexity of having multiple Cocoon
>>versions (I think we can ignore the servlet container difference for the
>>moment, that should not be taken into account IMO). We can have
>>each example
>>app deployed in its own war file, but with today's Cocoon runtime memory
>>size and twenty different applications, 2Gb or RAM will be soon
>>insufficient.
>>
>
>
> 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!
Ross
>
>
>>>>>How do people publish their content?
>>>>
>>>>Forrest is getting closer to making the automatic updating of content
>>>>from CVS repositories.
>>>>
>>>
>>>forrestbot is running since euh.. week or 2
>>>it's probably not the last incarnation of the thing, so there could be
>>>changes in the future, but it's running very stable over at our
>>
>>server to
>>
>>>produce http://outerthought.net/forrest (actually also runs for
>>>http://outerthought.net with different content and skin)
>>
>>Forrest can take care of publishing static documentation, but how about
>>deploying new functionality in an application? Especially those whose data
>>source is stored on the live system. I was arguing that we need a staging
>>area for such things, where people can actually test the
>>application before
>>pushing it on the live site.
>>
>
>
> different view:
> - we use forrest only for the documentation. and we use it as is to generate
> static content
> so pretty much of http://[cocoon-app-site].org/ would be static content
> pushed up there by the forrestbot (every 2h say)
> - only the apps would be doing dynamic/interactive stuff
> - as for staging/testing: couldn't we hope for that to have been done by the
> developer before checking in? probably he'll need to be able to specify some
> branch identifier to separate 'approoved and checked' from 'wip'
> (all in all, we might consider running the same environment on different
> portnumber, so one could have those two different branches indeed up and
> running as well?)
>
> uhuh, this makes me think again about the "little process" mentioned earlier
> have been running around with the idea to extract the bot ideas from
> forrestbot and maybe combine them with how gump is working to build some
> kind of a generic bot system that could be checking out code from a cvs repo
> and then start calling some specific ant targets in those different
> retrieved projects. (forrestot more or less does this, but is very
> forrest-only of course)
>
> so maybe the "little process" would be something that just
> - cvs co cocoon-apps
> - knows about the apps in there (by means of local file, or by means of how
> the repo is organized: dir-naming/special-descriptor.xml or the like)
> to know about would be: preferred cocoon version to run on, app-name,
> (list-off) ant targets to call to have it build/deploy locally?
>
> this would more or less only require us to have some known ant-properties
> set to tell these app-specific ant targets where they need to store stuff.
> (app-context-dir, ...)
>
> (euh, if we really have cocoon-apps, then there could just be a main
> build.xml that calls upon the others.)
>
> this approach would probably also allow apps to have ddl statements executed
> against some mysql or whatever (as long as people can express it in ant,
> right?)
>
>
>>>>>It would be great if
>>>>>we can get some thoughts on what we need here.
>>>>
>>>>I think the whole question of how and when things are published need to
>>>>be handled by Forrest. Perhaps people more active than I can comment on
>>>>how this would work.
>>>>
>>>
>>>see http://outerthought.net/forrest/forrest-contract.html
>>>I can easily give a hand on setting up the forrestbot conf for different
>>>projects
>>
>>Got it, thanks!
>>
>>Regards,
>>--
>>Ovidiu Predescu <ov...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon apps Web site hosting
Posted by Marc Portier <mp...@outerthought.org>.
> -----Original Message-----
> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>
> On 8/12/02 5:15 AM, "Marc Portier" <mp...@outerthought.org> wrote:
>
> >> Ovidiu Predescu wrote:
> >>> EUR CVS repository. Some developers might already have their own CVS
> >>> repositories, perhaps at SF, but others may choose to have it
> >> hosted here.
> >>
> >> I don't think the actual localtion of the CVS is particularly important
> >> as long as there is a central place to find out about the projects.
> > +1
> > most of this (mail lists et al.) can be organized at various places
> > the real difference would be in some kind of cocoon in ASP
> setup where the
> > different projects can be ran in their own cocoon environment: showcase
> > running apps before people get it from scratchpad of examples
> would be the
> > differentiator (and the hardest work: different cocoon versions possibly
> > different tomcat combinations...)
> >
> > that and the central website that talks about them.
>
> Yes, Marc, these are the core two things we need to capture.
>
> All projects hosted on the site should look similarly, check out
> MozDev.org
forrest skins should make this snap
and I would consider it good practice for all projects to think about being
skinned
> to see what I'm talking about:
>
> http://www.mozdev.org/projects.html
>
> The second is how to manage the complexity of having multiple Cocoon
> versions (I think we can ignore the servlet container difference for the
> moment, that should not be taken into account IMO). We can have
> each example
> app deployed in its own war file, but with today's Cocoon runtime memory
> size and twenty different applications, 2Gb or RAM will be soon
> insufficient.
>
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]/**
> >>> How do people publish their content?
> >>
> >> Forrest is getting closer to making the automatic updating of content
> >> from CVS repositories.
> >>
> >
> > forrestbot is running since euh.. week or 2
> > it's probably not the last incarnation of the thing, so there could be
> > changes in the future, but it's running very stable over at our
> server to
> > produce http://outerthought.net/forrest (actually also runs for
> > http://outerthought.net with different content and skin)
>
> Forrest can take care of publishing static documentation, but how about
> deploying new functionality in an application? Especially those whose data
> source is stored on the live system. I was arguing that we need a staging
> area for such things, where people can actually test the
> application before
> pushing it on the live site.
>
different view:
- we use forrest only for the documentation. and we use it as is to generate
static content
so pretty much of http://[cocoon-app-site].org/ would be static content
pushed up there by the forrestbot (every 2h say)
- only the apps would be doing dynamic/interactive stuff
- as for staging/testing: couldn't we hope for that to have been done by the
developer before checking in? probably he'll need to be able to specify some
branch identifier to separate 'approoved and checked' from 'wip'
(all in all, we might consider running the same environment on different
portnumber, so one could have those two different branches indeed up and
running as well?)
uhuh, this makes me think again about the "little process" mentioned earlier
have been running around with the idea to extract the bot ideas from
forrestbot and maybe combine them with how gump is working to build some
kind of a generic bot system that could be checking out code from a cvs repo
and then start calling some specific ant targets in those different
retrieved projects. (forrestot more or less does this, but is very
forrest-only of course)
so maybe the "little process" would be something that just
- cvs co cocoon-apps
- knows about the apps in there (by means of local file, or by means of how
the repo is organized: dir-naming/special-descriptor.xml or the like)
to know about would be: preferred cocoon version to run on, app-name,
(list-off) ant targets to call to have it build/deploy locally?
this would more or less only require us to have some known ant-properties
set to tell these app-specific ant targets where they need to store stuff.
(app-context-dir, ...)
(euh, if we really have cocoon-apps, then there could just be a main
build.xml that calls upon the others.)
this approach would probably also allow apps to have ddl statements executed
against some mysql or whatever (as long as people can express it in ant,
right?)
> >>> It would be great if
> >>> we can get some thoughts on what we need here.
> >>
> >> I think the whole question of how and when things are published need to
> >> be handled by Forrest. Perhaps people more active than I can comment on
> >> how this would work.
> >>
> >
> > see http://outerthought.net/forrest/forrest-contract.html
> > I can easily give a hand on setting up the forrestbot conf for different
> > projects
>
> Got it, thanks!
>
> Regards,
> --
> Ovidiu Predescu <ov...@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
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/12/02 5:15 AM, "Marc Portier" <mp...@outerthought.org> wrote:
>> Ovidiu Predescu wrote:
>>> EUR CVS repository. Some developers might already have their own CVS
>>> repositories, perhaps at SF, but others may choose to have it
>> hosted here.
>>
>> I don't think the actual localtion of the CVS is particularly important
>> as long as there is a central place to find out about the projects.
> +1
> most of this (mail lists et al.) can be organized at various places
> the real difference would be in some kind of cocoon in ASP setup where the
> different projects can be ran in their own cocoon environment: showcase
> running apps before people get it from scratchpad of examples would be the
> differentiator (and the hardest work: different cocoon versions possibly
> different tomcat combinations...)
>
> that and the central website that talks about them.
Yes, Marc, these are the core two things we need to capture.
All projects hosted on the site should look similarly, check out MozDev.org
to see what I'm talking about:
http://www.mozdev.org/projects.html
The second is how to manage the complexity of having multiple Cocoon
versions (I think we can ignore the servlet container difference for the
moment, that should not be taken into account IMO). We can have each example
app deployed in its own war file, but with today's Cocoon runtime memory
size and twenty different applications, 2Gb or RAM will be soon
insufficient.
>>> How do people publish their content?
>>
>> Forrest is getting closer to making the automatic updating of content
>> from CVS repositories.
>>
>
> forrestbot is running since euh.. week or 2
> it's probably not the last incarnation of the thing, so there could be
> changes in the future, but it's running very stable over at our server to
> produce http://outerthought.net/forrest (actually also runs for
> http://outerthought.net with different content and skin)
Forrest can take care of publishing static documentation, but how about
deploying new functionality in an application? Especially those whose data
source is stored on the live system. I was arguing that we need a staging
area for such things, where people can actually test the application before
pushing it on the live site.
>>> It would be great if
>>> we can get some thoughts on what we need here.
>>
>> I think the whole question of how and when things are published need to
>> be handled by Forrest. Perhaps people more active than I can comment on
>> how this would work.
>>
>
> see http://outerthought.net/forrest/forrest-contract.html
> I can easily give a hand on setting up the forrestbot conf for different
> projects
Got it, thanks!
Regards,
--
Ovidiu Predescu <ov...@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
RE: Cocoon apps Web site hosting
Posted by Marc Portier <mp...@outerthought.org>.
> Ovidiu Predescu wrote:
> > EUR CVS repository. Some developers might already have their own CVS
> > repositories, perhaps at SF, but others may choose to have it
> hosted here.
>
> I don't think the actual localtion of the CVS is particularly important
> as long as there is a central place to find out about the projects.
+1
most of this (mail lists et al.) can be organized at various places
the real difference would be in some kind of cocoon in ASP setup where the
different projects can be ran in their own cocoon environment: showcase
running apps before people get it from scratchpad of examples would be the
differentiator (and the hardest work: different cocoon versions possibly
different tomcat combinations...)
that and the central website that talks about them.
> However, a single domain name for the projects presents a feeling of
> coherence to the community as a whole.
>
> > EUR mailing lists and Web archives for them. Perhaps a better
> approach is to
> > have common mailing lists for all the applications (separated
> for users and
> > developer), so we can maintain a closer community. Should we
> reuse instead
> > Apache's mailing lists?
>
> The more we can stay within the Apache domain the better. The Apache
> name carries a good deal of respect in Industry.
>
> > EUR Web site presence. I think we need to have a combination of
> static pages
> > with dynamic ones, to show off examples and so on.
>
> It certainly needs to be Cocoon hosted!
>
> > For the Web site, I think
> > we need to maintain a common look and feel, just like Mozilla
> has for their
> > applications.
>
> Absolutely. Forrest is moving along quite nicely. I am using it across a
> couple of sites at the moment. It is still early in development and not
> really ready for the "big time" but I'm sure the project would benifit
> from more deveopers contributing ;-)
>
> > How do people publish their content?
>
> Forrest is getting closer to making the automatic updating of content
> from CVS repositories.
>
forrestbot is running since euh.. week or 2
it's probably not the last incarnation of the thing, so there could be
changes in the future, but it's running very stable over at our server to
produce http://outerthought.net/forrest (actually also runs for
http://outerthought.net with different content and skin)
> > Do they have access to a
> > staging area to test their site, and then publish it?
>
> I would say that the "staging" area is the developers own
> responsability. Once it is in CVS it is considered publishable. Would
> this mean maintaining a permanent branch for development work, keeping
> the main branch for approved bug fixes only? Or possibly the other way
> around, that is have a "release" branch for Forrest to publish from and
> leave HEAD as the development code?
>
> > It would be great if
> > we can get some thoughts on what we need here.
>
> I think the whole question of how and when things are published need to
> be handled by Forrest. Perhaps people more active than I can comment on
> how this would work.
>
see http://outerthought.net/forrest/forrest-contract.html
I can easily give a hand on setting up the forrestbot conf for different
projects
> > The last bullet seems to be the biggest item. It would be great
> if we can
> > come up with some more requirements on what it takes to have
> Web presence
> > for these applications, and then sketch out an implementation
> in Cocoon for
> > it.
>
> I would like to know how many people actually have applications that can
> be put into this environment. I for one am making noise about this but
> don;t __have__ anything to put in there yet. I intend to have something
> but that is __very__ different as you all know ;-) So lets also start a
> list of the real, working (even if only alpha) apps we have:
>
> * BringMeThis -
> http://www.superlinksoftware.com/cocoon/samples/bringmethis/ - Andrew C.
> Oliver
>
> Ross
>
>
> ---------------------------------------------------------------------
> 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
Re: Cocoon apps Web site hosting
Posted by Ross Gardler <rg...@wkwyw.net>.
>>>EUR Web site presence. I think we need to have a combination of static pages
>>>with dynamic ones, to show off examples and so on.
>>
>>It certainly needs to be Cocoon hosted!
>
>
> One issue I see, as somebody else noted as well, is that different examples
> will need possibly different versions of Cocoon. We need to manage this
> complexity somehow.
Yes, I think the web ring, with (eventualy) a central repository of
information distributed via RSS would be the best bet. Either my server
or the Outerthought server could be the control point for this.
For those who don't have access to the resources, I am sure I can
provide hosting on my server for them.
>>>Do they have access to a
>>>staging area to test their site, and then publish it?
>>
>>I would say that the "staging" area is the developers own
>>responsability. Once it is in CVS it is considered publishable. Would
>>this mean maintaining a permanent branch for development work, keeping
>>the main branch for approved bug fixes only? Or possibly the other way
>>around, that is have a "release" branch for Forrest to publish from and
>>leave HEAD as the development code?
>
>
> One thing which becomes difficult in the presence of dynamic data, is that
> is hard to test Web apps on a different machine without access to the data
> sources (databases etc.). That's why I think providing a separate staging
> area on the same server would be neat.
True.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
On 8/12/02 1:05 AM, "Ross Gardler" <rg...@wkwyw.net> wrote:
> Ovidiu Predescu wrote:
>> EUR CVS repository. Some developers might already have their own CVS
>> repositories, perhaps at SF, but others may choose to have it hosted here.
>
> I don't think the actual localtion of the CVS is particularly important
> as long as there is a central place to find out about the projects.
> However, a single domain name for the projects presents a feeling of
> coherence to the community as a whole.
As I said, I don't think this is important, especially if we have a common
apps repository hosted at Apache.
>> EUR mailing lists and Web archives for them. Perhaps a better approach is to
>> have common mailing lists for all the applications (separated for users and
>> developer), so we can maintain a closer community. Should we reuse instead
>> Apache's mailing lists?
>
> The more we can stay within the Apache domain the better. The Apache
> name carries a good deal of respect in Industry.
I agree.
>> EUR Web site presence. I think we need to have a combination of static pages
>> with dynamic ones, to show off examples and so on.
>
> It certainly needs to be Cocoon hosted!
One issue I see, as somebody else noted as well, is that different examples
will need possibly different versions of Cocoon. We need to manage this
complexity somehow.
> [...]
>
>> Do they have access to a
>> staging area to test their site, and then publish it?
>
> I would say that the "staging" area is the developers own
> responsability. Once it is in CVS it is considered publishable. Would
> this mean maintaining a permanent branch for development work, keeping
> the main branch for approved bug fixes only? Or possibly the other way
> around, that is have a "release" branch for Forrest to publish from and
> leave HEAD as the development code?
One thing which becomes difficult in the presence of dynamic data, is that
is hard to test Web apps on a different machine without access to the data
sources (databases etc.). That's why I think providing a separate staging
area on the same server would be neat.
>> It would be great if
>> we can get some thoughts on what we need here.
>
> I think the whole question of how and when things are published need to
> be handled by Forrest. Perhaps people more active than I can comment on
> how this would work.
Yes, it looks like Forrest would be the right thing.
>> The last bullet seems to be the biggest item. It would be great if we can
>> come up with some more requirements on what it takes to have Web presence
>> for these applications, and then sketch out an implementation in Cocoon for
>> it.
>
> I would like to know how many people actually have applications that can
> be put into this environment. I for one am making noise about this but
> don;t __have__ anything to put in there yet. I intend to have something
> but that is __very__ different as you all know ;-) So lets also start a
> list of the real, working (even if only alpha) apps we have:
>
> * BringMeThis -
> http://www.superlinksoftware.com/cocoon/samples/bringmethis/ - Andrew C.
> Oliver
I'm also working on a documentation system allowing user feedback. However
this should probably be placed under Forrest when is finished, I'm not sure.
Greetings,
--
Ovidiu Predescu <ov...@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
Re: Cocoon apps Web site hosting
Posted by Ross Gardler <rg...@wkwyw.net>.
Ovidiu Predescu wrote:
> EUR CVS repository. Some developers might already have their own CVS
> repositories, perhaps at SF, but others may choose to have it hosted here.
I don't think the actual localtion of the CVS is particularly important
as long as there is a central place to find out about the projects.
However, a single domain name for the projects presents a feeling of
coherence to the community as a whole.
> EUR mailing lists and Web archives for them. Perhaps a better approach is to
> have common mailing lists for all the applications (separated for users and
> developer), so we can maintain a closer community. Should we reuse instead
> Apache's mailing lists?
The more we can stay within the Apache domain the better. The Apache
name carries a good deal of respect in Industry.
> EUR Web site presence. I think we need to have a combination of static pages
> with dynamic ones, to show off examples and so on.
It certainly needs to be Cocoon hosted!
> For the Web site, I think
> we need to maintain a common look and feel, just like Mozilla has for their
> applications.
Absolutely. Forrest is moving along quite nicely. I am using it across a
couple of sites at the moment. It is still early in development and not
really ready for the "big time" but I'm sure the project would benifit
from more deveopers contributing ;-)
> How do people publish their content?
Forrest is getting closer to making the automatic updating of content
from CVS repositories.
> Do they have access to a
> staging area to test their site, and then publish it?
I would say that the "staging" area is the developers own
responsability. Once it is in CVS it is considered publishable. Would
this mean maintaining a permanent branch for development work, keeping
the main branch for approved bug fixes only? Or possibly the other way
around, that is have a "release" branch for Forrest to publish from and
leave HEAD as the development code?
> It would be great if
> we can get some thoughts on what we need here.
I think the whole question of how and when things are published need to
be handled by Forrest. Perhaps people more active than I can comment on
how this would work.
> The last bullet seems to be the biggest item. It would be great if we can
> come up with some more requirements on what it takes to have Web presence
> for these applications, and then sketch out an implementation in Cocoon for
> it.
I would like to know how many people actually have applications that can
be put into this environment. I for one am making noise about this but
don;t __have__ anything to put in there yet. I intend to have something
but that is __very__ different as you all know ;-) So lets also start a
list of the real, working (even if only alpha) apps we have:
* BringMeThis -
http://www.superlinksoftware.com/cocoon/samples/bringmethis/ - Andrew C.
Oliver
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ovidiu Predescu wrote:
>I think what we need to come up with is a general structure for the projects
>hosted. What exactly do we want to offer? This is the list I can think of so
>far:
>
>EUR CVS repository. Some developers might already have their own CVS
>repositories, perhaps at SF, but others may choose to have it hosted here.
>
>
If given the karma, I am an experienced CVS hacker. (and I think I
remember how to pipe it through ssh,
if not I'm sure It'll come to me)
>EUR mailing lists and Web archives for them. Perhaps a better approach is to
>have common mailing lists for all the applications (separated for users and
>developer), so we can maintain a closer community. Should we reuse instead
>Apache's mailing lists?
>
>
I would say at least at first, keep it with Cocoon. The more its
seperated, the more invisible it is.
>EUR Web site presence. I think we need to have a combination of static pages
>with dynamic ones, to show off examples and so on. For the Web site, I think
>we need to maintain a common look and feel, just like Mozilla has for their
>applications. How do people publish their content? Do they have access to a
>staging area to test their site, and then publish it? It would be great if
>we can get some thoughts on what we need here.
>
>
For the static ones, that's what Centipede/Forrest are good for (we use
this for POI and I believe its used
for avalon). For dynamic ones, cocoon with a basic XSLT and an XSP page
with a CINCLUDE taking its src
from an XSP request parameter. This will provide the basic
left,top,bottom part and include the content in the
middle. That way we get the *basic* look and feel without bugging the
heck out of people.
This seems to be largely a duplication of what Krysalis.org wants to do,
perhaps moving it to your server, would
provide us with:
1. The consistant look and feel
2. An already springboarded community with Cocoon and Avalon committers
making up a part already.
3. The talents of Nicola Ken to help with the *pretty stuff* that I
can't do as well as increadibly good ideas on how to structure things,
even if he's totally allergic to documenting it. (I think it gives him
hives)
It would give them
1. Something that doesn't crash all the time like sourceforge....
Seems like a match. The only downside would be this might be a
subproject rather than *the thing*, but I bet something could be worked out.
Regardless, I still thing we need a cocoon-apps module *here*. More for
*cocoon-lightweight-example-apps* but thats a bit wordy.
-Andy
>The last bullet seems to be the biggest item. It would be great if we can
>come up with some more requirements on what it takes to have Web presence
>for these applications, and then sketch out an implementation in Cocoon for
>it.
>
>Regards,
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
I think what we need to come up with is a general structure for the projects
hosted. What exactly do we want to offer? This is the list I can think of so
far:
CVS repository. Some developers might already have their own CVS
repositories, perhaps at SF, but others may choose to have it hosted here.
mailing lists and Web archives for them. Perhaps a better approach is to
have common mailing lists for all the applications (separated for users and
developer), so we can maintain a closer community. Should we reuse instead
Apache's mailing lists?
Web site presence. I think we need to have a combination of static pages
with dynamic ones, to show off examples and so on. For the Web site, I think
we need to maintain a common look and feel, just like Mozilla has for their
applications. How do people publish their content? Do they have access to a
staging area to test their site, and then publish it? It would be great if
we can get some thoughts on what we need here.
The last bullet seems to be the biggest item. It would be great if we can
come up with some more requirements on what it takes to have Web presence
for these applications, and then sketch out an implementation in Cocoon for
it.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
On 8/11/02 10:32 AM, "Andrew C. Oliver" <ac...@apache.org> wrote:
> How can I help?
>
> -Andy
>
> Ovidiu Predescu wrote:
>
>> Steven,
>>
>> I've already paid money to get an account to an ISP for exactly this type of
>> setup. At that time I was talking to other cocoon developers about setting
>> up such a site to showcase Cocoon. Unfortunately, none of us had sufficient
>> spare energy to pull this out and to start working on it. At the moment it
>> hosts only the Weblogs of myself and Jeff Turner, and Berin's and us email
>> accounts, but it will soon host the Anteater Web site as well.
>>
>> The vision of this is to have a loosely coupled group of developers, which
>> have similar interests and work on similar projects, to share the same
>> resources. Long term, I'd like us to become a center of expertise for other
>> companies to hire us, either individually or as a group, to provide support
>> and custom enhancements to these projects.
>>
>> I'm offering this site to host the Cocoon web site you're talking about, as
>> it shares the same vision I had when I started it. We have 1Gb of hard-disk
>> space available and 10Gb of transfer monthly, which should be plenty for the
>> time being. Unfortunately we have only 1 shell account available, but I
>> think we can increase that to three accounts with little additional cost,
>> which can then be shared among us.
>>
>> I already have a CVS repository setup for multiple developers, we can create
>> mailing lists and setup a Cocoon hosting environment for Cocoon apps.
>>
>> Please let me know if this is something which might interest you.
>>
>> Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon apps Web site hosting
Posted by "Andrew C. Oliver" <ac...@apache.org>.
How can I help?
-Andy
Ovidiu Predescu wrote:
>Steven,
>
>I've already paid money to get an account to an ISP for exactly this type of
>setup. At that time I was talking to other cocoon developers about setting
>up such a site to showcase Cocoon. Unfortunately, none of us had sufficient
>spare energy to pull this out and to start working on it. At the moment it
>hosts only the Weblogs of myself and Jeff Turner, and Berin's and us email
>accounts, but it will soon host the Anteater Web site as well.
>
>The vision of this is to have a loosely coupled group of developers, which
>have similar interests and work on similar projects, to share the same
>resources. Long term, I'd like us to become a center of expertise for other
>companies to hire us, either individually or as a group, to provide support
>and custom enhancements to these projects.
>
>I'm offering this site to host the Cocoon web site you're talking about, as
>it shares the same vision I had when I started it. We have 1Gb of hard-disk
>space available and 10Gb of transfer monthly, which should be plenty for the
>time being. Unfortunately we have only 1 shell account available, but I
>think we can increase that to three accounts with little additional cost,
>which can then be shared among us.
>
>I already have a CVS repository setup for multiple developers, we can create
>mailing lists and setup a Cocoon hosting environment for Cocoon apps.
>
>Please let me know if this is something which might interest you.
>
>Regards,
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon apps Web site hosting
Posted by Ovidiu Predescu <ov...@apache.org>.
Steven,
I've already paid money to get an account to an ISP for exactly this type of
setup. At that time I was talking to other cocoon developers about setting
up such a site to showcase Cocoon. Unfortunately, none of us had sufficient
spare energy to pull this out and to start working on it. At the moment it
hosts only the Weblogs of myself and Jeff Turner, and Berin's and us email
accounts, but it will soon host the Anteater Web site as well.
The vision of this is to have a loosely coupled group of developers, which
have similar interests and work on similar projects, to share the same
resources. Long term, I'd like us to become a center of expertise for other
companies to hire us, either individually or as a group, to provide support
and custom enhancements to these projects.
I'm offering this site to host the Cocoon web site you're talking about, as
it shares the same vision I had when I started it. We have 1Gb of hard-disk
space available and 10Gb of transfer monthly, which should be plenty for the
time being. Unfortunately we have only 1 shell account available, but I
think we can increase that to three accounts with little additional cost,
which can then be shared among us.
I already have a CVS repository setup for multiple developers, we can create
mailing lists and setup a Cocoon hosting environment for Cocoon apps.
Please let me know if this is something which might interest you.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
On 8/8/02 7:01 AM, "Steven Noels" <st...@outerthought.org> wrote:
> Carsten Ziegeler wrote:
>
>> Or sourceforge?
>>
>> We should not use the cocoon cvs for cocoon-apps, I don't
>> now the official "apache policy" on this. It is very good
>> to have a cocoon-apps area, but I don't want to give all
>> 'cocoon-apps' committers also access to cocoon itself.
>> So it must be separated.
>
> Sourceforge is good as a development environment, but it will not give
> us the means of *showcasing* Cocoon apps. We will end up with
> (hopefully) some portal site, but a miriad of little project sites
> around this. I think Cocoon will be served better if we can group all
> these applications under one umbrelle.
>
> OK, here's my deal:
>
> I'm dreaming of a Cocoon application development community, comparable
> to SF, with CVS, mailinglists, and a Cocoon-app deployment environment.
> I've been dreaming about this for the past few weeks and did some
> homework. I've been figuring out the costs of hosting such a machine and
> securing it sufficiently, and I might even consider to jumpstart this
> entirely on our (=outerthought) own budget. No big iron server to start
> with, of course, just as CocoDocoWiki is run right now.
>
> Consider it to be CocoKrysalis. Now if other companies are willing to
> co-sponsor this, they are welcome. This will cost *real* money.
>
> In terms of opportunity management, it might not be wise to post such
> statements knowing I'm going offline in a few hours. But since the
> opportunity is there, and we are being confronted with the need for such
> an environment, I hope you will give me some time to gather all this in
> some plan, and come back to it in a few weeks. I'm dead-serious about this.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org