On 4 Dec 2003, at 01:54, Daniel Florey wrote:
at
WebDAV doesn't support observation, nor I know any draft that proposes
this (am I wrong?), so I think the API for observability will be putIt willthe Slide API level, or even in the domain.xml file.No, there is no webDAV draft for event handling as far as I know.
The first step will be to implement event handling at Slide API level.someaffect many classes, but I think it is worth to do so. There will belistenerskind of event dispatcher that can be requested via NamespaceAccessToken.getEventHelper() ... ). You can register eventsomefor different types of events and fire events. The dispatcher will doofevent filtering to speed up event dispatching (as there might be a lotBut what if the content is not accepted for any reason? Any serious contenttraffic lateron). My goal is to keep it as simple as possible.
Hmmmm..... To me this begs the question, why is it not part of webDAV?
And I think the answer is that webdav is a lower level protocol, for the
*safe* transport, storage and retrieval of data in groups.
So basically I think adding vetoable events at this level is a bad idea.
If the user, for some reason, should not store the file in a certain
place, he should not have write permissions for that place. More than
this adds levels of non-determinism and uncertainty to an operation that
should be safe.
management solution should be able to do some kind of content/referential
integrity checking, so there is a number of reasons why an operation could
fail, not only permissions. If webDAV is not able to give the user some
additional feedback on the occured error, it should be extended. I'll look
into the protocol to check if some error messages can be sent.
What if a user commits a set of files, with different events being firedThe transaction will be rolled back if one event fires a veto.
for each one, some of them vetoing, some not?
As for non-vetoing events, this seems ok, but then why not stick with the listeners?
I think there are much better places for the event logic. As has been
pointed out in numerous threads, slide is not a full content management
system, it is more like a repository at the moment. Layers like workflow
and presentation are missing entirely, and are realized by combining
slide with other Servlets/Web Applications to build a full system. This
is the place to put such events, not in the repository logic.
Richie
Slide started as a full cms, even though it is more like a content
repository at the moment. But remember that it is the base for many content
management solutions. And one very importent part is the ability to check
referential integrity or validate content. This must be done in a tranaction
aware manner. What if you are uploading some documents in a single
transaction and one of it fails because of some reason? The whole
transaction must be rolled back. This can not be achieved by the use of
interceptors at the moment. So I think vetoable events are an elegant
solution which enables slide to be used as a transactional content
repository.
If you only use slide as a simple webDAV-Folder this might sound a little
bit overdosed, but if you think of it as a content repsitory this is a must.
As much as I dislike the idea of turning Slide into a full blown CMS, I very much agree with Daniel here: transactional observability is a must for serious content repositories.
At the same time, the issue is must debated even in big CMS circles, as much so that Observability is currently optional in JSR-170 because some vendors dislike it to have it at the repository level (or can't implement it, but this is a different story).
But design of those event mechanism is *really* tricky.
My personal suggestion, for the future of this projects, would be for Slide to implement JSR-170 once it's finalized, instead of reinventing the wheel [we already have an implementation of it in the /proposal/jcrri/ section. (JCRRI stands for Java Content Repository Reference Implementation)]
Note that JCR is a highly feature complete CR API and two years of design were spent into it.
--
Stefano, who is currently in San Francisco where he will be attending the JSR-170 face2face meeting to finalize the latest issues of the spec.. hoping to get it public soon.
Ah, all ASF members are legally entitled to have a copy of the spec since it's in community review. So, ask me a copy: the more and earlier feedback the better.
smime.p7s
Description: S/MIME cryptographic signature
