[Bug 46783] [next] Fix FileTransfer ContentHash property

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2012-09-14 09:29:54 UTC ---
Any progress on this? I'd really like to see bug #42909 fixed so best to fix
the spec in 1.0 first.

(In reply to comment #6)
> (In reply to comment #4)
> > Maybe it would be worth supporting less dummy protocol where the file hash is
> > sent *after* having sent the file and so saving the sender from reading the
> > file twice on disk.
> > 
> > But I have no idea if any protocol supports this. Maybe jingle file transfer?
> 
> You're right about jingle file transfer.
> 
>     http://xmpp.org/extensions/xep-0234.html#hash
> 
> Given it's obviously nicer to send the hash afterwards so I'll have a think
> about it for when we implement jingle FT (any day now!)

We can't know before requesting the channel if the CM is going to use a FT
method allowing the hash to be set afterwards or not (the receiver may or may
not support jingle FT). So we need a new immutable property returned by
CreateChannel telling us this. Maybe something like this:
  ContentHashSupport : No, BeforeSending, AnyTime

If ContentHashSupport == No then ContentHash(Type) are ro during all the
lifetime of the channel.

If ContentHashSupport == BeforeSending then ContentHash(Type) can be set
until ProvideFile() is called.

Not sure until when ContentHash(Type) can be set if ContentHashSupport ==
AnyTime.
Actually it's not clear to me from the XEP how the receiver is supposed to
know that a hash will be send and so wait for it before presenting the FT has
'done' to the user.

> (In reply to comment #5)
> > Looking at this again in the context of AccountChannelRequest helper API, it
> > seems wrong that we have a (type, hash) pair. We're basically unable to tell
> > clients which hash type can be used!
> > 
> > We might be better off with something more like this:
> > 
> > property ContentMD5 : s, read, request:sometimes, immutable
> > property ContentSHA1 : s, read, request:sometimes, immutable
> > property ContentSHA256 : s, read, request:sometimes, immutable
> 
> Why not a:
> 
> property AvailableContentHashTypes : au, read, immutable
> 
> Am I missing something here?

Maybe that's something that could be merged with ContentHashSupport : uau ?

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