Problems with file transfer API

[Tomasz Wasilczyk]

Hi,

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 
devel.

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 
transfer protocol.

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 
transfer methods:
- 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 
a one-liner.

Tomek

PS: isn't it a good idea for a GSoC project?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4225 bytes
Desc: Kryptograficzna sygnatura S/MIME
URL: <https://pidgin.im/pipermail/devel/attachments/20140217/5523db59/attachment.bin>