Re: core-dev Digest, Vol 17, Issue 7
Aidan Steele <[email protected]> Mon, 17 Oct 2005 06:30:12 +1000
| Newsgroups | gmane.network.gnutella.limewire.core.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, Yes, that is what I had in mind! I will get started on something within a few hours and submit it. On 10/17/05, Zlatin Balevsky <[email protected]> wrote: > An easier thing to do is to allow registering multiple > ActivityCallbacks and dispatching events to all of them. A side > effect of such approach is that every front end will be encouraged to > implement the full functionality of ActivityCallback. :) > > Splitting ActivityCallback into sub-callbacks will require a lot more > work on our part, and while we are in general supportive of the idea, > we can't promise it will be happening anytime soon. > > On 10/15/05, Aidan Steele <[email protected]> wrote: > > In my development of a web frontend for LimeWire / FrostWire, I've > > noticed that the current callback implementation will not be enough. > > Currently, only one callback can be registered and that is > > VisualConnectionCallback (the link between the GUI and the backend). > > > > I notice the comment in the above class: "It implements the > > ActivityCallback callback interface, designed to make it easy to swap > > UIs." This is easy enough, but multiple concurrent callbacks are not > > possible. > > > > I am proposing a new implementation of the ActivityCallback interface > > to be registered with the RouterService. This new implementation would > > hold a list of callbacks (GUI, HTTP, Instant Messaging, Email, et al) > > which would *all* be called when a specific method of the 'master' > > callback is called. This list could be added to during program > > execution through the usage of a List or somesuch. > > > > The benefit of the above approach means that we would not have to > > modify the existing callback (VisualConnectionCallback) at all, simply > > create an abstraction layer for it. Whether or not this specific > > method is used is not important, but further development of LimeWire / > > FrostWire would be greatly improved with this change. > > > > -- > > Aidan Steele. > > > > _______________________________________________ > > core-dev mailing list > > [email protected] > > http://www.limewire.org/mailman/listinfo/core-dev > > > > > > > > > _______________________________________________ > core-dev mailing list > [email protected] > http://www.limewire.org/mailman/listinfo/core-dev > > > -- Aidan Steele. _______________________________________________ core-dev mailing list [email protected] http://www.limewire.org/mailman/listinfo/core-dev