from bug #39188: Let's say it's called TpFTHelper for now. Perhaps something like this: TpFTHelper * tp_ft_helper_new_outgoing ( TpAccount *); void tp_ft_helper_send_file_async ( TpFTHelper *, GFile *source, GHashTable *asv, GAsyncReadyCallback, gpointer); gboolean tp_ft_helper_send_file_finish ( TpFTHelper *, GAsyncResult *, GError **); GObject properties: guint64: transferred-bytes (including change notification) TpFTHelperState: state (including change notification) send_file should do this: 1. Hash the GFile; 2. request the channel with additional properties given in the asv argument (like Metadata.ServiceName, Metadata.Metadata); 3. call provide_file at the right time; 4. call the callback once the transfer is complete. Empathy's file transfer window only needs to know a few things: 1. When the file gets accepted (this is currently not done by a state change but when the transferred bytes property "changes" to zero). 2. When hashing has started and when hashing has stopped. 2. When bytes are sent. notify::transferred-bytes is fine for this. 3. When the transfer is complete. notify::state is fine for this too. This feels a lot like EmpathyFTHandler. (I have actually already ported Empathy to use the new TpFTChannel methods; see https://bugzilla.gnome.org/show_bug.cgi?id=663682) TpFTHelper * tp_ft_helper_new_incoming ( TpFileTransferChannel *); void tp_ft_helper_receive_file_async ( TpFTHelper *, GFile *destination, GAsyncReadyCallback, gpointer); gboolean tp_ft_helper_receive_file_finish ( TpFTHelper *, GAsyncResult *, GError **); receive_file should do this: * Call accept_file on the TpFTChannel; * hash the file either on the way in (ideally), or hash the file after the transfer is complete (less cool); * call the callback when the transfer is complete. The same properties and change notification can work for incoming too. The _new_* functions could take the GFile instead of waiting and giving it to send/receive? (Guillaume said) > (In reply to comment #1) > > Let's say it's called TpFTHelper for now. Perhaps something like this: > > Looks good to me.
Something I don't like here is that the process doing the channel request must be also sending the file data and do the hashing, right? It's a bit annoying in the case of a call-ui having an extra send-file action; if the call ends we could want to terminate call-ui process but still have the FT running, no? So I'm wondering if it makes sense to request a FT channel with URI set (or even not that) and then rely on the handler to do hashing and ProvideFile call (and even popup the file chooser to select which file to send in case URI is not set at request). Does this makes sense or am I on crack?
Motivation: call-ui is prone to crashes, I don't want to have my FT to fail because the clutter/X/driver/gst failed at something.
(In reply to comment #1) > Something I don't like here is that the process doing the channel request must > be also sending the file data and do the hashing, right? The hash properties are immutable and requestable so the process doing the channel request must also do the hashing... that's just a spec limitation. I've opened bug #46783 in order to fix this for 1.0 but until then, it's just a fact. This helper thing was designed with this limitation in mind though. > So I'm wondering if it makes sense to request a FT channel with URI set (or > even not that) and then rely on the handler to do hashing and ProvideFile call > (and even popup the file chooser to select which file to send in case URI is > not set at request). Well unless I'm misunderstanding, this can't be done yet; see bug #46783 again.
As a starting point, I got EmpathyFTHandler building inside tp-glib. See attached branch. I then copied and pasted it into the feature/tubes2 branch of LibreOffice in the meantime… it'd be nice to drop that.
http://cgit.collabora.com/git/user/wjt/telepathy-glib/commit/?h=ft-helper&id=4dbbe906ab320f201bf1d63cdc7096ae0215a85b and http://cgit.collabora.com/git/user/wjt/telepathy-glib/commit/?h=ft-helper&id=083236e06b092f1ab0b5dc0cd6fcb930feb1a54b look good to me. How far are we to merge the 'next' spec branch to master? Maybe we should wait for bug #46783 to be fixed first as that will change this helper API. Or maybe we should just implement it for now and changes its API later; don't know.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/79.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.