Now that we've got a next branch, we can fix this: FileTransfer.ContentHash is really annoying because it means the person requesting the channel must be the one who hashes the file. We should fix this by: 1. specifying that the file send request is sent when ProvideFile() is called, and not when the new channel is created. 2. making ContentHash and ContentHashType mutable *before* ProvideFile() has been called (just like the URI property). Of course for incoming file transfers, it's always immutable. So here is the outgoing file transfer case: 1. request a FileTransfer channel in some dummy app with: { ChannelType: FileTransfer, TargetHandleType: CONTACT, TargetID: "foo@bar.com", URI="file:///home/user/party.jpg" } 2. the appropriate channel appears and another app is activated as the handler. The handler sees the file is /home/user/party.jpg and hashes it to get the hash "abcdefghijklmnopqrstuvwxyz". So calls: Set("FileTransfer", "ContentHashType", 1337) Set("FileTransfer", "ContentHash", "abcdefghijklmnopqrstuvwxyz") 3. the handler then calls ProvideFile(). 4. the CM then sends the, say, SI file transfer stanza. The incoming transfer case is pretty much the same. How does this sound then?
(In reply to comment #0) > How does this sound then? Entirely reasonable, if I'm interpreting it correctly: > The incoming transfer case is pretty much the same I assume you mean "... the same as it always was" rather than "the same as the outgoing case"? ContentHashType is chosen by the sender, and ContentHash is computed by the sender, surely? (Including "sender does not send a hash", which you could view as a sort of trivial choice/computation.) I think the semantics of CH, CHT are sort of the opposite of URI: you can meaningfully set URI right up until you Accept an incoming file transfer, but not afterwards, and it's immutable on outgoing FTs; conversely, you can meaningfully set CH, CHT right up until you Provide an outgoing FT, but they're immutable on incoming FTs.
(In reply to comment #1) > Entirely reasonable, if I'm interpreting it correctly: Great, I'll make the spec changes and submit them for review here. > I assume you mean "... the same as it always was" rather than "the same as the > outgoing case"? Yes.
Okay here's a patch to do this. HTML is here: http://people.freedesktop.org/~jonny/telepathy-spec-ft_46783/spec/Channel_Type_File_Transfer1.html I took this opportunity to try and fix up the rest of the interface. It might just be easier to look at the HTML.
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?
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
(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!) (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?
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 ?
(In reply to comment #6) > property AvailableContentHashTypes : au, read, immutable Ideally this property should depend of the contact you want to send a file to. We could use http://xmpp.org/extensions/xep-0300.html#disco to check which hashing algo are supported by the peer.
Even then, jingle could fail and gabble could fallback to normal FT and then it will need the hash sooner. In which case maybe we need a signal "I-need-the-hash-now" and handler then call ProvideHash().
(In reply to comment #9) > Even then, jingle could fail and gabble could fallback to normal FT and then it > will need the hash sooner. In which case maybe we need a signal > "I-need-the-hash-now" and handler then call ProvideHash(). Actually forget that :-) Setting blocker.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/133.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.