----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Friday, December 05, 2003 6:15 PM Subject: Re: Events in Slide
> > On 4 Dec 2003, at 01:54, Daniel Florey wrote: > > >>>> > >>>> 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 put > > at > >>>> the 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. > > It will > >>> affect many classes, but I think it is worth to do so. There will be > > some > >>> kind of event dispatcher that can be requested via > >>> NamespaceAccessToken.getEventHelper() ... ). You can register event > > listeners > >>> for different types of events and fire events. The dispatcher will do > > some > >>> event filtering to speed up event dispatching (as there might be a > >>> lot > > of > >>> traffic 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. > > But what if the content is not accepted for any reason? Any serious > > content > > 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 > >> fired > >> for each one, some of them vetoing, some not? > > The transaction will be rolled back if one event fires a veto. > > > >> 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. I still like the idea of integrating some kind of presentation layer and process engine to slide :-) But I'll shut up until the repository part is finished... > > 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)] Do you think of replacing the slide API by the JSR-170 in a long term? > > 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. I'd really like to get a copy! I've looked into the api that comes with slide some time ago and there've been some things I was a little bit confused about. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
