Problems with file transfer API
twasilczyk at pidgin.im
Mon Feb 17 04:06:32 EST 2014
there were a off-list discussion about the problems with our FT API, but
I think it's worth to bring it a wider audience, so I'm posting this to
The problem is, our FT API is extremely complicated. Moreover, it still
lacks a lot of cases, so prpls using it still needs to be complicated
too. The complication level peaks, if we want to implement atypical file
The whole discussion was started by a set of bugs I introduced by the
chance of implementing purple_xfer_[read|write]_file(). For example:
there is a do_transfer() function in xfer.c, which takes care of
purple_xfer_set_bytes_sent(); purple_xfer_write_file() also calls this,
so the set_bytes routine is called twice. But if we call *_file()
directly, it's set only once.
The purple_xfer_[read|write]_file routines were aimed to reduce the
complexity and code duplication. Just look at mxit_xfer_rx_file
(mxit/filexfer.c) or mw_ft_recv (sametime.c). Prpls should deal only
with receiving the data stream and passing it to the FT API, not with
writing the file to the disk. Even the FT API doesn't handle this, if
ui_write is defined.
Mark said, that bytes_sent was intended for exactly reflecting the
number of bytes that have been sent or received over the network. But in
some cases, the number of bytes transferred doesn't match the length of
the file (i.e., when file transferred is base64 encoded).
--- summary ---
The root cause for FT API complication is that it tries to fit different
file transfer protocols (while it still cannot fit all of them). Look at
purple_xfer_start() - there is an option to pass a file descriptor
(yahoo, oscar, xmpp, irc, bonjour), ip and port (xmpp, irc), or even
don't pass anything (mxit, msn, xmpp, gg).
I think, this API needs to be totally rewritten. The idea: let's define
a base PurpleXfer class, which just passes the data from prpl to the UI
or the file. Then, define few classes that implements common file
- by passing a file descriptor with raw file contents
- by passing a ip:port pair to connect and retrieve raw file contents
- (new) by passing a pre-configured PurpleHttpRequest, to download or
upload the file
Prpls could implement their own PurpleXfer implementations (dereiving
from the base class, or the specific sub-classes). Also, the prpl side
should be as simple as possible. Ideally, the prpl's "recv_cb" should be
PS: isn't it a good idea for a GSoC project?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4225 bytes
Desc: Kryptograficzna sygnatura S/MIME
More information about the Devel