On 3 Dec 2003, at 13:27, Daniel Florey wrote:
Hi,
I'd like to open a new thread to share my thoughts on event handling in slide.
I would like to start working on this issue at the beginning of the next year.
My basic thoughts are:
- Events should be fired for every operation that could be of interest for any
recipient.
- There should be two types of events: Evens that are fired inside
transactions (vetoable events) and events that are distributed as a bundle at
the end of a transaction. So events should be able to replace interceptors
(that are currently not transaction-aware).
- The events that are fired should contain a reference to the content that it
belongs to. So it should be possible to check the content of a document
inside a transaction if the vetoable write event occurs and deny it if
needed. Btw: There should be a way to read the stream of a resource without
confusing slide (so that slide can read from the stream again to write the
resource).
- The events should be extendable so that custom events can be fired and
distributed in the same way as "core" events.
The events should be able to connect parts of slide without coupling them too
tightly. Think of some kind of presentation layer with caching, integration
of lucene or a workflow engine.
In a first step events are fired inside the VM, maybe some event listeners
could be used distribute them via JMS later to enable clustered environments.
I'd like to use naming conventions that are similar to swing events (events,
listeners, adaters...) because everything should sound familiar and I think
swing/awt is the place where events are used most frequently.
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.
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?
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
