Bug 47936 - jingle-share protocol silently drops most file transfer properties & metadata
Summary: jingle-share protocol silently drops most file transfer properties & metadata
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard: libreoffice-tubes
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 01:37 UTC by Will Thompson
Modified: 2012-07-19 14:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Thompson 2012-03-27 01:37:13 UTC
When offering a file transfer, if the peer has the jingle-share cap and we have a Google relay token, Gabble prefers to use jingle-share (using a confusing bit of logic in gabble_file_transfer_channel_offer_file() which I am about to clarify).

Unfortunately, the offer includes almost none of the Channel.Type.FileTransfer or Channel.I.FileTransfer.Metadata properties:

* iq xmlns='jabber:client' type='set' to='yyy' id='77863471642'
    * session xmlns='http://www.google.com/session' initiator='xxx' id='568990973' type='initiate'
        * description xmlns='http://www.google.com/session/share'
            * manifest
                * file size='5343'
                    * name
                        "write-manager-file.py"
            * protocol
                * http
                    * url name='source-path'
                        "/temporary/fefff52b-3e03-40a1-8370-6bed61a4935b/"
                    * url name='preview-path'
                        "/temporary/68a248ad-1173-4abc-80ae-66e0614aadc1/"
        * transport xmlns='http://www.google.com/transport/p2p'

This broke my attempt to use Metadata.ServiceName to make LibreOffice a BypassApprovers-flavoured handler for file transfers directed to it. It also broke my follow-up attempt to (ab)use Description for the same purpose.

Whether or not adding extra data (like ContentType, etc.) to the <file/> element would break Google clients, it seems reasonable (at the very least) to include everything if we know the peer supports our Metadata extension.
Comment 1 Will Thompson 2012-03-27 02:14:43 UTC
(In reply to comment #0)
> (using a confusing bit
> of logic in gabble_file_transfer_channel_offer_file() which I am about to
> clarify).

Confusing enough that I misunderstood it while trying to simplify it. Hooray for tests. I'll just leave it.
Comment 2 Will Thompson 2012-07-17 13:56:21 UTC
So, more specifically. offer_bytestream() in ft-channel.c adds desc="" attributes etc. and also calls add_metadata_forms(): http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/ft-channel.c#n1195

But when using the GTalk file transfer protocol, offer_gtalk_file_transfer() is called instead <http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/ft-channel.c#n1339> which ultimately calls produce_description() <http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/jingle-share.c#n443> which as you can see does not add a description or anything.


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.