On Wed, 2003-12-03 at 16:14, Daniel Florey wrote:I must agree with you that event logic should be in the applications on top of Slide, and neither part of the WebDAV protocol or fully implemented IN Slide. That doesn't mean that there should not be support for events in Slide that will allow these applications to register an observer and act on the events as part of Slide Transactions, which is what I believe Daniel and Stefano are recommending. If the Slide Repository doesn't support these events, then no bolt on application is going to be 100% reliable as there will always be a way around the event logic, through programmer error or intrusion. Slide doesn't need to and arguably should not implement anything but the observable interface and an external transaction boundary.
All of this sounds very nice to me. I have just a few questions.No, there is no webDAV draft for event handling as far as I know.
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.
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. What if a user commits a set of files, with different events being fired
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.
Ollie
Richie
What do you mean by slide user? There might be some kind of client API to connect to the server to register on special events lateron (push and pull mode), but the first step will be server side only. We implemented this in our product, but it is of course still proprietary. I think it will be hard to add support for active callbacks to WebDAV. (Maybe we can think about some kind of call to get all events since the last one. But for this we would need a session context.)How do you envision observability to work from a slide user/configuration perspective?
I like the concept of active observation, but I don't understand how
you want to design it. In order to trigger a veto on a transation, the
observation needs to be blocking on the "beforeCommit" event. Isn't
this a potential problem?
If you trigger a veto in a vetoable event, the enclosing transaction will be rolled back. I didn't thought of a "beforeCommit" event - what should this be good for? I simply thought of something that is similar to the PropertyChangeEvent in java.beans. If for example a resource will be moved you can register on the "macro"-event (or however it will be called) and throw a veto exception or even simpler return false in the callback method if the interface was
interface VetoableMacroListener {
boolean resourceMove(VetoableMacroEvent macroEvent);
boolean resourceCopy(VetoableMacroEvent macroEvent);
...
}
Did not thought of naming yet...
Daniel
--
Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
