You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stephan Michels <st...@vern.chem.tu-berlin.de> on 2002/06/04 09:21:15 UTC

Thoughts about requirements for a cms


On Tue, 4 Jun 2002, Brian Topping wrote:

> > -----Original Message-----
> > From: Stephan Michels [mailto:stephan@vern.chem.tu-berlin.de]
> > Sent: Tuesday, June 04, 2002 1:57 AM
> > To: Brian Topping
> > Subject: RE: [VOTE] Peter Royal and Stephan Michels as committers
> >
> > Help are ever welcome ;-)
>
> Great, have you had any considerations on how you might want to move forward?  Any
> thoughts on how you might integrate the CMS against C2?  Ideas whether
> there is anything that might fit the bill to start with?

I think what be useful for the first time is an projection of a loaction
in a repository on a url. My first initial stage was:

slide://<namespace>/<uri of the resource>?username=<principal>&revision=<revision>

Slide used the 'namespace' as a name for the repository, so they be able
to have more than one repository.

For the next stage, I need something like a DirectoryGenerator to be able
to browse through the repository.

And the next stage were to have a SlideTransformer to modify the
repository, like adding a new user, removing content etc.

> The three things that I am interested in seeing in a CMS is:
>
> 1) that it can produce content from a distributed client Generator.  Ideally, the
> generator would be something similar to a JDBC client with pooling and
> distributed cache invalidation such that the content is referenced with
> something like an XPath on the server and pulled in.

Jakarta Slide have a WebDAV servlet, so you able to access the repository
via http. Searching is no so easy, this will be a job for a sitemap
component.

> 2) that there is support for the in-place editing with the "CONTENTEDITABLE"
> attribute.  I don't know a lot about this, but Q42 Xopus is doing this
> and apparently is putting their technology into Mozilla 1.1.  I don't
> care either way about M$, but I do like where Q42 is going.

My knowledge about "CONTENTEDITABLE" is very limited, but I think this is
not the best way.

> 3) even though Xindice would be a natural and easy way to store documents,
> I believe a real enterprise-class solution still needs to work
> inexpensively on a SQL database.  From my own experience, this really
> comes down to a single factor, the integration of nightly hot backups
> and support.  Very few of the ODBMS or free RDBMS solutions can do this,
> and IMHO it's a big limitation for 24x7 operations.  It's tough to
> solve, vendors charge for it, and it's a checklist item for many companies that
> think they will need it.

Slide has many 'store' implementations, so you can store the content in a
filesystem, or in a database, perhaps there will be a store implementation
for xindice.
At the moment Tamino comes with WebDAV support using by Jakarta Slide.

> Thoughts so far?  Do you have any hard requirements?

One thing I really like are the ContentInterceptors. With these
interceptors you are able to validate the content, e.g. against a DTD,
before you store the content.

> Also, have you heard of Wyona?  They have some basic skeleton code operational.
> Their goal is to make the CMS simply a transport between various XML
> web-service'ish providers.

Yes, this also a good way. What I really like from wyona is the 'Workflow
Markup Language'
http://www.wyona.org/docs/wyona-cms-docs/developer-guide/wf/index.html

> There is also JSR-170 that Stefano mentioned
> the other day.  My comments on these two is that they may be years to
> implementation; if we can leverage one of them to be successful sooner,
> we should, and if not, question it.  One part of the programmer ego in
> me would like to see something survive for a long time, the other part
> would like to release a robust solution quickly.  Your thoughts here are
> very relevant as well.

I would like to start with slide, but for the future JSR-170 is the better
way.

> I have operational mail servers if you want to set up a mailing list in the
> future, but while it is small, there is no reason yet.

If we not disturbing anyone, we could using the cocoon dev list? *duck*


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


Re: Thoughts about requirements for a cms (WebDAV vs. Slide API)

Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.

On Tue, 4 Jun 2002, Bertrand Delacretaz wrote:

> On Tuesday 04 June 2002 10:18, Stephan Michels wrote:
> >. . .
> > Pro's :
> >  * you will be indepedent from the  back-end.
>
> In theory yes.
> But running the backend in a separate process is also very important IMHO.
> You won't get JAR or JDK version conflicts with slide or whatever WebDAV
> backend you're using. Makes the whole thing easier to test too.

Yes, totally agree.

> >
> > Contra's :
> >  * More overhead, so it will be slower
>
> That's the price to pay for modularity and thin interfaces.
> In my book it's worth it 99% of the time.
>
> >  * Worry about if you have all possibilities as from a direct access, e.g.
> >    revision control.
>
> WebDAV provides DeltaV for this, but I don't know if Slide implements it
> already. If not, it's always possible to abstract the revision stuff so that
> it can use DeltaV when available. Same for DASL if it's not available in
> Slide today

After a look into the org.apache.webdav.* from Slide, I think pretty
clean. They have revision control and search support in the webdav client
libary.

> >  * Easier to implement
>
> And learning to program WebDAV is more "reusable" knowledge than learning the
> Slide API I think.
>
> So I'm all for a WebDAV interface to content stores!

Okay okay, I think also. The good thing you could separate the WebDAV
Server another maschine, that really an argument.

So we need something like dav://<uri>?principal=<name>&password=<bla>

Ps. I hate the namespace 'DAV:', but anyway... ;-)

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
 <D:prop xmlns:R="http://www.foo.bar/boxschema/">
  <R:bigbox/>
  <R:author/>
  <R:DingALing/>
  <R:Random/>
 </D:prop>
</D:propfind>


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


Re: Thoughts about requirements for a cms (WebDAV vs. Slide API)

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 04 June 2002 10:18, Stephan Michels wrote:
>. . .
> Pro's :
>  * you will be indepedent from the  back-end.

In theory yes.
But running the backend in a separate process is also very important IMHO. 
You won't get JAR or JDK version conflicts with slide or whatever WebDAV 
backend you're using. Makes the whole thing easier to test too.

>
> Contra's :
>  * More overhead, so it will be slower

That's the price to pay for modularity and thin interfaces. 
In my book it's worth it 99% of the time.

>  * Worry about if you have all possibilities as from a direct access, e.g.
>    revision control.

WebDAV provides DeltaV for this, but I don't know if Slide implements it 
already. If not, it's always possible to abstract the revision stuff so that 
it can use DeltaV when available. Same for DASL if it's not available in 
Slide today.

>  * Easier to implement

And learning to program WebDAV is more "reusable" knowledge than learning the 
Slide API I think.

So I'm all for a WebDAV interface to content stores!

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.






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


Re: Thoughts about requirements for a cms

Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.

On Tue, 4 Jun 2002, Bertrand Delacretaz wrote:

> On Tuesday 04 June 2002 09:21, Stephan Michels wrote:
> >. . .
> > slide://<namespace>/<uri of the
> > resource>?username=<principal>&revision=<revision>
> >. . .
>
> Isn't it possible to use slide through its WebDAV interface rather than over
> a call-level API? The question is pointless if you have code already, but if
> you're starting from scratch it might be worth a tought.

No, it isn't pointless, throught about by myself. Something like writeable
dav source.

Pro's :
 * you will be indepedent from the  back-end.
 * using standards like 'DAV ACL', 'Delta V' or 'DASL'

Contra's :
 * More overhead, so it will be slower
 * Worry about if you have all possibilities as from a direct access, e.g.
   revision control.
 * Easier to implement

I doesn't know which is the better way :-|

> Being able to run slide in a different process would be a big plus IMHO, and
> it might open up the possibility of using other content stores.
>
> >. . .
> > Jakarta Slide have a WebDAV servlet, so you able to access the repository
> > via http. Searching is no so easy, this will be a job for a sitemap
> > component.
> >. . .
>
> The slide homepage says "DASL support", shouldn't this be usable for
> searching the content?

I see... of cause yes.
http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html



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


Re: Thoughts about requirements for a cms

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 04 June 2002 09:21, Stephan Michels wrote:
>. . .
> slide://<namespace>/<uri of the
> resource>?username=<principal>&revision=<revision>
>. . .

Isn't it possible to use slide through its WebDAV interface rather than over 
a call-level API? The question is pointless if you have code already, but if 
you're starting from scratch it might be worth a tought.

Being able to run slide in a different process would be a big plus IMHO, and 
it might open up the possibility of using other content stores.

>. . .
> Jakarta Slide have a WebDAV servlet, so you able to access the repository
> via http. Searching is no so easy, this will be a job for a sitemap
> component.
>. . .

The slide homepage says "DASL support", shouldn't this be usable for 
searching the content?

-Bertrand

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


Re: Thoughts about requirements for a cms

Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> 
> Matthew Langham wrote:
> > Stefan wrote:
> > <
> > Stafano (!) of course.
> >
> > Matthew
> 
> STAFANO????
> --^

whatever... :)

You can go along so nice without me that you started to forget how to
spell my name... sheesh...

You guys will drive me to Perl one of these days. :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


RE: Thoughts about requirements for a cms

Posted by Matthew Langham <ml...@s-und-n.de>.
>>
STAFANO????
--^
<<

.... Carsten pointed that one out to me straight away :-). 

Matthew

 

-----Original Message-----
From: Ugo Cei [mailto:u.cei@cbim.it]
Sent: Wednesday, June 05, 2002 2:12 PM
To: cocoon-dev@xml.apache.org
Subject: Re: Thoughts about requirements for a cms


Matthew Langham wrote:
> Stefan wrote:
> <
> Stafano (!) of course.
> 
> Matthew

STAFANO????
--^

	ROTFL,
		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: Thoughts about requirements for a cms

Posted by Ugo Cei <u....@cbim.it>.
Matthew Langham wrote:
> Stefan wrote:
> <
> Stafano (!) of course.
> 
> Matthew

STAFANO????
--^

	ROTFL,
		Ugo



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


RE: Thoughts about requirements for a cms

Posted by Matthew Langham <ml...@s-und-n.de>.
>
Stefan wrote:
<
Stafano (!) of course.

Matthew



-----Original Message-----
From: Matthew Langham [mailto:mlangham@s-und-n.de]
Sent: Wednesday, June 05, 2002 12:27 PM
To: cocoon-dev@xml.apache.org
Subject: RE: Thoughts about requirements for a cms


Stefan wrote:

>>
I'm not a father, but I think this might barely resemble the feeling a
father gets when a child/daughter grows up and stand on his/her feet.
Hmmm...
<<
Hmm.. I am a father of 3 - and I guess Cocoon is probably easier :-). But I
think you are right. To some extent I think "creating" something and then
releasing it to the public (whether that be software, artistic works such as
books etc.) brings on the same feeling. "What's going to happen" "Will they
manage without me". It's all about letting go. Something we all find very
hard to do.

>>
Some say software takes 10 years to develop. I tend to see this is a
reasonable estimate for closed-source software. I have the perception
that the rate of growth of a healthy and diverse open source community
is much faster. Probably twice as fast. In this case, Cocoon has two
more years to go before becoming adult.
<<
I think this is spot-on. Although - looking at what has happened in the past
year - Cocoon may grow up faster than we all expect.

>>
I wonder what I'll end up doing next.
<<
Ok, this is a teaser - right :-)? What ARE you doing....?

>>
Ah, enough wining...
<<
It's not whining - it's speaking with a voice. A personal voice. And that is
the power of open source communities - and Cocoon in particular.

Matthew

--
Open Source Group       Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
  http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================



-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: Tuesday, June 04, 2002 2:15 PM
To: cocoon-dev@xml.apache.org
Subject: Re: Thoughts about requirements for a cms


Stephan Michels wrote:
>
> On Tue, 4 Jun 2002, Stefano Mazzocchi wrote:
>
> > Stephan Michels wrote:
> >
> > > I think what be useful for the first time is an projection of a
loaction
> > > in a repository on a url. My first initial stage was:
> > >
> > > slide://<namespace>/<uri of the
resource>?username=<principal>&revision=<revision>
> >
> > If you make this a WriteableSource, I'm sure many will start to use it
> > right away instead of writing stuff on the file system.
>
> It is a WriteableSource ;-)

Know what? sometimes I wonder why I bother keeping myself subscribed to
this mail list: you people do an incredible job even without any
guidance.

I'm not a father, but I think this might barely resemble the feeling a
father gets when a child/daughter grows up and stand on his/her feet.
Hmmm...

Some say software takes 10 years to develop. I tend to see this is a
reasonable estimate for closed-source software. I have the perception
that the rate of growth of a healthy and diverse open source community
is much faster. Probably twice as fast. In this case, Cocoon has two
more years to go before becoming adult.

I wonder what I'll end up doing next.

Hmmm, probably try to find a way to make some money without missing all
the fun of those environments where money is not the fuel of things.

Ah, enough wining...

--
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
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: Thoughts about requirements for a cms

Posted by Matthew Langham <ml...@s-und-n.de>.
Stefan wrote:

>>
I'm not a father, but I think this might barely resemble the feeling a
father gets when a child/daughter grows up and stand on his/her feet.
Hmmm...
<<
Hmm.. I am a father of 3 - and I guess Cocoon is probably easier :-). But I
think you are right. To some extent I think "creating" something and then
releasing it to the public (whether that be software, artistic works such as
books etc.) brings on the same feeling. "What's going to happen" "Will they
manage without me". It's all about letting go. Something we all find very
hard to do.

>>
Some say software takes 10 years to develop. I tend to see this is a
reasonable estimate for closed-source software. I have the perception
that the rate of growth of a healthy and diverse open source community
is much faster. Probably twice as fast. In this case, Cocoon has two
more years to go before becoming adult.
<<
I think this is spot-on. Although - looking at what has happened in the past
year - Cocoon may grow up faster than we all expect.

>>
I wonder what I'll end up doing next.
<<
Ok, this is a teaser - right :-)? What ARE you doing....?

>>
Ah, enough wining...
<<
It's not whining - it's speaking with a voice. A personal voice. And that is
the power of open source communities - and Cocoon in particular.

Matthew

--
Open Source Group       Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
  http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================



-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: Tuesday, June 04, 2002 2:15 PM
To: cocoon-dev@xml.apache.org
Subject: Re: Thoughts about requirements for a cms


Stephan Michels wrote:
>
> On Tue, 4 Jun 2002, Stefano Mazzocchi wrote:
>
> > Stephan Michels wrote:
> >
> > > I think what be useful for the first time is an projection of a
loaction
> > > in a repository on a url. My first initial stage was:
> > >
> > > slide://<namespace>/<uri of the
resource>?username=<principal>&revision=<revision>
> >
> > If you make this a WriteableSource, I'm sure many will start to use it
> > right away instead of writing stuff on the file system.
>
> It is a WriteableSource ;-)

Know what? sometimes I wonder why I bother keeping myself subscribed to
this mail list: you people do an incredible job even without any
guidance.

I'm not a father, but I think this might barely resemble the feeling a
father gets when a child/daughter grows up and stand on his/her feet.
Hmmm...

Some say software takes 10 years to develop. I tend to see this is a
reasonable estimate for closed-source software. I have the perception
that the rate of growth of a healthy and diverse open source community
is much faster. Probably twice as fast. In this case, Cocoon has two
more years to go before becoming adult.

I wonder what I'll end up doing next.

Hmmm, probably try to find a way to make some money without missing all
the fun of those environments where money is not the fuel of things.

Ah, enough wining...

--
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
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: Thoughts about requirements for a cms

Posted by Stefano Mazzocchi <st...@apache.org>.
Stephan Michels wrote:
> 
> On Tue, 4 Jun 2002, Stefano Mazzocchi wrote:
> 
> > Stephan Michels wrote:
> >
> > > I think what be useful for the first time is an projection of a loaction
> > > in a repository on a url. My first initial stage was:
> > >
> > > slide://<namespace>/<uri of the resource>?username=<principal>&revision=<revision>
> >
> > If you make this a WriteableSource, I'm sure many will start to use it
> > right away instead of writing stuff on the file system.
> 
> It is a WriteableSource ;-)

Know what? sometimes I wonder why I bother keeping myself subscribed to
this mail list: you people do an incredible job even without any
guidance.

I'm not a father, but I think this might barely resemble the feeling a
father gets when a child/daughter grows up and stand on his/her feet.
Hmmm...

Some say software takes 10 years to develop. I tend to see this is a
reasonable estimate for closed-source software. I have the perception
that the rate of growth of a healthy and diverse open source community
is much faster. Probably twice as fast. In this case, Cocoon has two
more years to go before becoming adult.

I wonder what I'll end up doing next.

Hmmm, probably try to find a way to make some money without missing all
the fun of those environments where money is not the fuel of things.

Ah, enough wining...

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Re: Thoughts about requirements for a cms

Posted by Jeremy Quinn <sh...@mac.com>.
On Tuesday, June 4, 2002, at 12:38 PM, Stephan Michels wrote:

>
>
> On Tue, 4 Jun 2002, Stefano Mazzocchi wrote:
>
>> Stephan Michels wrote:
>>
>>> I think what be useful for the first time is an projection of 
>>> a loaction
>>> in a repository on a url. My first initial stage was:
>>>
>>> slide://<namespace>/<uri of the 
>>> resource>?username=<principal>&revision=<revision>
>>
>> If you make this a WriteableSource, I'm sure many will start to use it
>> right away instead of writing stuff on the file system.
>
> It is a WriteableSource ;-)
>

Top man!

One innocent question (sorry, I am completely new to Slide).


Say you were going to make a file-based repository to be managed 
by Slide.

Say you wanted to access this repository via Slide for editing 
purposes only, but publish files to actual users via the 
(faster?) FileGenerator, does Slide leave you with a coherent 
file hierarchy to read directly? Or, once you use Slide as your 
repository, every access MUST go through Slide?

thanks for any help

I liked Stefano's (?) idea, a repository that is accessed 
through Slide for version management, but via Xindice for user 
access, taking advantage of XPath queries on whole collections.

regards Jeremy


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


Re: Thoughts about requirements for a cms

Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.

On Tue, 4 Jun 2002, Stefano Mazzocchi wrote:

> Stephan Michels wrote:
>
> > I think what be useful for the first time is an projection of a loaction
> > in a repository on a url. My first initial stage was:
> >
> > slide://<namespace>/<uri of the resource>?username=<principal>&revision=<revision>
>
> If you make this a WriteableSource, I'm sure many will start to use it
> right away instead of writing stuff on the file system.

It is a WriteableSource ;-)

Stephan Michels.


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


Re: Thoughts about requirements for a cms

Posted by Stefano Mazzocchi <st...@apache.org>.
Stephan Michels wrote:

> I think what be useful for the first time is an projection of a loaction
> in a repository on a url. My first initial stage was:
> 
> slide://<namespace>/<uri of the resource>?username=<principal>&revision=<revision>

If you make this a WriteableSource, I'm sure many will start to use it
right away instead of writing stuff on the file system.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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