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