[Telepathy] Some FileTransfer spec comments

[Sjoerd Simons]

On Tue, Nov 04, 2008 at 10:43:57AM +0000, Guillaume Desmottes wrote:
> Le mardi 04 novembre 2008 à 00:11 +0000, Jonny Lamb a écrit :
> > > - 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.

Only the receiver can request an offset in XEP-0096:
 When <range> is sent in the offer, it should have no attributes. This
 signifies that the sender can do ranged transfers. When a Stream Initiation
 result is sent with the <range> element, it uses these attributes:
    * offset - Specifies the position, in bytes, to start transferring the
      file data from. This defaults to zero (0) if not specified.
    * length - Specifies the number of bytes to retrieve starting at offset.
      This defaults to the length of the file from offset to the end.

When you Request a FT channel, it is always to offer a file. You cannot Request
an FT channel to receive a file.

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

If you don't want the socket approach, then you need let the CM place the file
somewhere on the filesystem. Which is not something you want imho.

You want the client to have the opportunity to save it wherever they want,
which might be on a virtual filesystem, just to memory to open it right
away or even put it in say a photo database. So an open file button may or may
not make sense.

My feeling is that the ``download manager'' should either be the handler if the
user choose save file to disk. Or the actual handler should do some action
after finishing the download (in which case only showing progress is good
enough, as open this file may or may not actually make sens).

  sjoerd
-- 
There's only one everything.