On Wed, 2003-12-03 at 16:14, Daniel Florey wrote: > > > > All of this sounds very nice to me. I have just a few questions. > > > > 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.
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.
Richie
> > 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?
> 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.)
> 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]
>
>
signature.asc
Description: This is a digitally signed message part
