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. > > > 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. > > > - 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. > > > - 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. > > > Any comments are welcome! > > Keep up the great work! > > > -- > > 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]
