[Telepathy] Some FileTransfer spec comments

[Guillaume Desmottes]

Le mardi 04 novembre 2008 à 00:11 +0000, Jonny Lamb a écrit :
> 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..


I'm talking about ContentType (as image/jpeg for example), not the 
ContentHashType.

ContentType's descriptions says: "This property is mandatory when
requesting the channel with the
Connection.Interface.Requests.CreateChannel method."
So either it's not mandatory, either we should add it to the list of the
mandatory properties.

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

Not sure. For example XEP-0096 allows to send a file with an initial
offset.


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

Indeed, that's crack.
Tbh, I'm not convinced by this socket approach...

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

Wouldn't it make sense to have a channel type containing all the common
properties and signals?


	G.