Am Donnerstag, 22. Januar 2004 14:50 schrieb Stefano Mazzocchi: > 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?
Yes. They are some kind of replacement for interceptors, but I'll keep interceptors untouched as some applications may rely on them. I'll post the patches next week (as soon as they are in a state where the basics are reliable) so that everyone can give comments. > > >>> 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. > > >>> - 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. > > > > I thought of clients that are behind firewalls so that only http/https > > port is > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
