> -----Original Message----- > From: Stephan Michels [mailto:[EMAIL PROTECTED]] > Subject: Thoughts about requirements for a cms > > 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>
I hadn't really done much thinking about slide before. One of my concerns is that the performance is sufficient to base a production system on, but of course this performance could be developed incrementally. I trust that Slide will do it's part to be as efficient as practical, I am more concerned that we are able to interface to Slide in a manner that is potentially an in-process call for the URL resolution. Again, these are optimizations, I just want to be sure from the outset that the path is there. If WebDAV was the *only* access to the repository, I would be more concerned (slide has direct access APIs as well that we could emulate the same result through)... Regardless, the more I consider your proposal, the more I like it (for whatever that is worth ;) > Slide used the 'namespace' as a name for the repository, so > they be able > to have more than one repository. yes, this is grand. > 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. This isn't too different than the ideas in the authentication components, for purposes of architectural sanity, I propose that we stick with their patterns wherever possible. > > 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. On their 2.0 list is integration with Lucene, shouldn't we go that way as the conduit for searching? > > 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. I'm interested in your thoughts on alternatives to this. I may not have been clear enough in the context of Slide: CONTENTEDITABLE is an orthogonal access method, not the only one. The user can choose the Slide method, CONTENTEDITABLE, maybe even adapters such as FTP, NFS and SMB (but these belong in Slide...) The demo that Q42 has online is very compelling. Browser support for a solution we provide is *not* a given, and if we can layer that on top of what Slide already provides, it could be really powerful. > > 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. Yes, I'm comfortable not worrying about that with Slide on the job :-) > > 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. No complaints here ;) > I would like to start with slide, but for the future JSR-170 > is the better > way. What you propose sounds very reasonable and could probably have many users well before JSR-170 sees the light of day. > > 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* Even better, just wanted to offer... An additional issue that also comes to mind is that of user/group/role repositories. I'd like to see that these are unified (or at least have the ability to unify) against the authentication manager. Multiple user repositories is a completed system is a hassle. -b --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
