On Tue, 4 Jun 2002, Brian Topping wrote:
> > -----Original Message-----
> > From: Stephan Michels [mailto:[EMAIL PROTECTED]]
> > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
