cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@vern.chem.tu-berlin.de>
Subject Thoughts about requirements for a cms
Date Tue, 04 Jun 2002 07:21:15 GMT


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


Mime
View raw message