Well thats great implement the Callback on SimpleRequestClient and use the
callback, i'm attaching the changed version.....
A few thots...
How about changing the structure of Conduit from doing just a single
callback to handle multiple callback objects, something like event/listener
model where u register the callback and the Conduit propogates the callback
to all of them with maybe a few parameters? Guess it would provide for a
better developement of GUI's on top of the basic framework. and maybe
generalise the counter to also work on top of this, tying down the counter
so hard into the heart of conduit does seem to be a very good idea ........
A status window which logs the messages instead of having it on the
console.......
Regards
Jebu Ittiachen
----- Original Message -----
From: "Oskar Sandberg" <[email protected]>
To: <freenet-dev at lists.sourceforge.net>
Sent: Sunday, April 09, 2000 2:08 PM
Subject: Re: [Freenet-dev] Improved FGUI
>
> This is not so. If you look, the asyncFeed method takes two callbacks. If
you
> give it both, the second will be called if the stream ends before the
correct
> number of bytes have been read, while the first is called if finishes.
>
> On Sun, 09 Apr 2000, Paul Kappler wrote:
> > The Callback Idea is almost what we need here. The problem is: the
callback
> > has no way of knowing if there was an IOException or if the transfer was
> > successful. Perhaps the callback could take the Exception as a
parameter or
> > null if there was success. This will need changes everywhere the
callback
> > is used but I think all the code could benefit if it knew there was a
> > exception.
> >
> > Paul Kappler
> >
> >
> > > From: Oskar Sandberg <md98-osa at nada.kth.se>
> > >
> > > The conduit can take an implementation of the support/Callback
interface and
> > > call that when it is finished. This is used for closing the network
stream
> > > after sending a message with a trailing field in
ConnectionHandler.java for
> > > example.
> > >
> > > It isn't that different from doing it in the Counter's finished
method, but it
> > > is more in line with what the different objects were meant for.
> > >
> >
> >
> > _______________________________________________
> > Freenet-dev mailing list
> > Freenet-dev at lists.sourceforge.net
> > http://lists.sourceforge.net/mailman/listinfo/freenet-dev
> --
>
> Oskar Sandberg
>
> md98-osa at nada.kth.se
>
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleRequestClient.java
Type: application/octet-stream
Size: 2294 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20000409/279c768a/attachment.obj>
