Re: [Gaim-devel] Oscar FT update

[William T. M. <wt...@du...>]

On Sun, Nov 10, 2002 at 02:23:47PM -0500, Sean Egan wrote:
> I share Chip's concern.  When I first sat down to write the file
> transfer GUI was the first time I looked at the API and I noticed this
> right away.  Wouldn't it be better for the prpl to handle its sockets
> itself and have its own callback which can strip headers and stuff and
> then call a generic function with a pointer and a length?  That would
> seem to be the optimal solution.

I agree that this seems like a good generic solution, given the
situation Chip described.  This wasn't really an oversight in the API,
but rather an intentional assumption.  Although I admit it was a poor
one, as Paco and others have pointed out.

The main drawback to your method is that there will be some
duplication of code in each of prpls (the read/write while loops).  I
supppose it's worth it to have a simpler interface, though.  I'll work
on implementing something like what you suggest.

> Apart from writing gtkcellrendererprogress, I've not started the file
> transfer GUI--Rob may have started--either way changes to ft.c would not
> interfere with it much, I'm sure.

OK, I'll focus on these changes to the generic interface then, since
it seems to be most in need of work.

-- Wil
P.S.  Not to nag, but I hope someone remembers to apply my patch that
started this thread. :-)