[Bug 31376] TpFileTransferChannel : high level API for FT

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Danielle Madeley <danielle.madeley at collabora.co.uk> 2011-03-04 14:15:19 PST ---
(In reply to comment #6)

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

That means they need to be included in the channel-request, not that they need
to be exposed as properties. It's already complicated to create the
channel-request, you need to look up all the properties from the GFile, so
perhaps an extra utility function that creates the channel request from the
GFile is required (I think you've been adding other channel-request builders to
tp-glib, right?).

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

I suppose you could have the object own a GDateTime that gets unreffed on
finalize and just return pointers to it.

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

Yeah. It makes it easier for a simple file transfer "did it work or not", and a
file transfer observer can then additionally use the state to show extra
information.

~

Another thought: the 'uri' property will be automatically set from the GFile,
right? We don't need a setter for that.

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