On 21 Jan 2004, at 15:20, Daniel Florey wrote:
Am Mittwoch, 21. Januar 2004 14:49 schrieb Stefano Mazzocchi:On 21 Jan 2004, at 14:34, Daniel Florey wrote:As promised I now started to work on event handling in slide.
Awesome!!
[hey, the evolution rate of this project is unbelievable!]
It's not easy to find the right approach to fire as many events as desired.
don't worry, we can tune things later... don't try to make it perfect the first try, my suggestion is to have something that work ASAP and let the community make it better over time. Incremental community development is the fastest process.
I'll do so - but it affects many files in the core (share/) classes so I'll
wait at least until the 2.0 branch is forked.
ok, are your changes back compatible?
I've implemented vetoable events for the different helpers
(ContentEvent,
MacroEvent etc), but this is very fine grained. (BTW: It's interesting
to
see, how ofter some methods are called, there seems to be much room for
performance enhancements).
Yes! it's a very nice tracing and debugging mechanism as well!
There may also be events on level of each webDAV method but I've the strong feeling it is better to handle event on slide core level only.
+1
Next steps: - Make the events to be fired configurable (per helper?)
what do you mean by "helper"?
StructureHelper, ContentHelper etc. I thought of applications only interested
in content events, they should be able to configure that only ContentHelper
methods will fire events.
Oh, I see. Sounds good to me.
I thought of clients that are behind firewalls so that only http/https port is- Collect events that are fired inside transactions and distribute them
asynchronously to all listeners after commit (for this the stores
might need
to be extended so that events can be stored to ensure that no event
gets
lost). This can e.g. be used to trigger search index updates.
nice!
- event en-/decoding to XML
what's the reason for this? [curious]
- Implement webdav-like method to get all events since... (time in millis) for client that want to pull events
hmmm, again, what's the scenario for this? I expect events to be pushed, polling is not exactly the most efficient mechanism of synchronization.
open. They can pull the changes in a short interval so that they have the
feeling they get events pushed. This is really not a preferrable solution
because it can cause some traffic on low intervals, but it is essential for
client applications that rely on getting informed about server side changes.
ok
- Implement pushing events to remote clients listening on a specified port (webdav-like method needed to register clients on a given port)
Have you thought about using JMS instead?
I wanted to keep the events open to other languages than java.
Good point.
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
