Problems with file transfer API

Ankit Vani a at nevitus.org
Mon Feb 17 11:38:17 EST 2014


On Mon, Feb 17, 2014 at 2:36 PM, Tomasz Wasilczyk <twasilczyk at pidgin.im> wrote:
> 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.

In the gobj.plugins branch, a protocol can implement the
PurpleProtocolFactoryIface and implement the xfer_new function of it to return
an object of a protocol-specific subclass of PurpleXfer (called if defined, by
purple_xfer_new).

The appropriate file transfer functions can be made virtual and added to
PurpleXferClass. The protocol-specific subclasses can override whatever virtual
functions they need to.



More information about the Devel mailing list