[Bug 31376] TpFileTransferChannel : high level API for FT

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31376

--- Comment #6 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-03-04 00:26:20 PST ---
(In reply to comment #3)
> (In reply to comment #1)
> state, content-type, filename, size, description, date, transferred-bytes and
> uri should all be GObject properties.

Agreed.

> I'm not sure it's useful to expose initial-offset, content-hash or
> content-hash-type, these are all internal to the channel (the channel should
> deal with the initial offset, and also confirm the hash for us -- we need a
> mechanism to know the hash is bad though).

Not sure about that. Sjokkis and I already discussed hashs and the problem is
for outgoing channels. You have to compute the hash *before* requesting the
channel (as that's an immutable prop) so we can't do it in
TpFileTransferChannel as it doesn't exist yet. Having hash being handled by
TpFileTransferChannel for incoming channels but not for outgoing ones sound
weird to me.

So our current plan was to not handle them in TpFileTransferChannel and create
later an higher FT helper object which will.

This is just the current state of our brainstorming sessions, I'm ready to be
convinced that's a bad idea.

> I think we should also add a "transferred-percentage" property which is a
> double ranging from [0,1], this allows programmers to create a GBinding to bind
> the file transfer channel straight to a GtkProgressBar.

That's a great idea; I love it!

> > Signals
> > -------
> > 
> > "transferred-bytes-changed" (guint64 count);
> 
> Just use notify::transferred-bytes -- this also lets users bind the transferred
> bytes to a GtkLabel via a transform function to pretty print it (I'd say we
> should provide that function, but tp-glib doesn't provide i18n, we should get
> something for it in GLib perhaps).

Good idea.

(In reply to comment #4)
> (In reply to comment #2)
> > > gint64 *tp_ft_channel_get_date (TpFTChannel *self);
> > 
> > Maybe we could use a GDateTime instead?
> 
> GDateTimes require memory management (unreffing etc). Perhaps it's better to
> return a gint64 and let the user create a GDateTime if it's useful to her? Or
> we could have both accessors.

I don't get your point here. tp_file_transfer_channel_get_date_time (); will
return a (transfer none) GDateTime object so that's pretty convenient to use.

> > > void tp_ft_channel_accept_async (TpFTChannel *self,
> > >     guint64 offset,
> > >     GFile *file,
> > >     GCancellable *cancellable,
> > >     GAsyncReadyCallback callback,
> > >     gpointer user_data);
> > 
> > I'd swap the offset and file args.

agreed.

> > When are these operations succeeding? As soon as the D-Bus call returns or
> > when the sending/receiving is done?
> 
> I was wondering the same thing. Do these return once the FT is set up (in which
> case you need to monitor the state) or once the transfer is complete (in which
> case we don't need to expose the state, we can just return whatever we want in
> the GError).

I'd be tempted for the latter, that seems easier and more convenient to use.

(In reply to comment #5)
> (In reply to comment #2)
> 
> > > TpFTState *tp_ft_channel_get_state (TpFTChannel *self);
> > 
> > That's TpFileTransferState.
> > 
> > Do we really want to expose this to the user? If we succeed send/receive
> > operation when the sending is done, can't we just use the GError of the
> > _finish() function to tell user about failures?
> 
> Actually, I've thought about this, and we do want to expose state, it's useful
> in the UI, so we can do strings like "Waiting for the recipient to accept the
> file".

That's a good point, but I'm stil tempted to think that terminating the async
operation when the transfer is complete (or failed) is a good idea.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.