[Telepathy] Some FileTransfer spec comments

[Jonny Lamb]

On Mon, Nov 03, 15:46:09 +0000, Guillaume Desmottes wrote:
> - "In order to send a file, one should request a FileTransfer channel
> for a contact, and fill the mandatory properties (Filename, and Size)"
> We should add the ContentType to the list of mandatory properties.

It was discussed in a spec meeting some time ago that ContentType (or
ContentMD5 at the time) should not be mandatory. Annoyingly though, I
cannot remember the reason. This isn't very helpful..

> - Reading at the spec, it wasn't clear to me if the InitialOffset can be
> set when requesting the FT channel or not. This sentence made me think
> it can't "until the state changes to Open, this property is undefined"
> but it seems I was wrong. Spec should be clearer.

Right. To clarify, InitialOffset cannot be set when requesting the FT
channel. This highlights the fact that one can only receive an non-zero
offset transfer when the transfer is offered to this person in the first
place. This sounds like a problem, no?

> - When receiving a file, the Filename property is the suggested name of
> the file, not the full path to which the file is being transferred. So,
> if we have an Observer displaying download progression status, it won't
> be able to display the name chosen by the user when he accepted the FT.

Indeed. Changing the contents of the Filename property to the receiver's
choice of filename would fix this...

> Furthermore, once the download is finished, the Observer won't be able
> to display a "Open this file" button as it won't know the full path.

...but not this. I suppose one workaround would be to "when receiving a
file, after calling AcceptFile, then Filename should be set with the
full path of the save location" but this all sounds a little on crack
now.

> - This socket approach could be problematic in some CM. For example,
> libpurple's FT API only use file path.
> Maybe we should have move current AcceptFile, OfferFile and
> AvailableSocketTypes to a FileTransfer.Socket interface and have a
> FileTransfer.FilePath (or similar) interface implementing Accept/Offer
> using path. The rest of the current FT channel type will stay common I
> think.

So, I was asked to write an o.f.T.Channel.Type.FileTransfer.LocalFile
interface for just that. However, would it be better to have
FileTransfer.{Socket,File} interfaces?

Thanks,

-- 
Jonny Lamb, UK
jonnylamb at jonnylamb.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20081104/cfab7b44/attachment.pgp