>
> 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.
>
> 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]
