[Standards-JIG] File transfer in MUC

Mridul mridul at sun.com
Sat Oct 14 12:15:22 UTC 2006


  Please see inline.


Michal 'vorner' Vaner wrote:
> On Sat, Oct 14, 2006 at 06:30:31AM +0530, Mridul wrote:
>> Ian Paterson wrote:
>>> Mridul wrote:
>>>> It will not allow the user to 'attach' a file to the conference - so 
>>>> that people joining the conference 'later on' also have a way to 
>>>> retrieve the file.
>>>> Ofcourse , one way to look at it is , if you were not online when I 
>>>> tried sending you a file - you dont get it : like in normal case :-)
>>> Perhaps it's not what you are looking for, but one excellent multicast 
>>> file transfer solution has been available for years...
>>> The client HTTP POSTs the file to a friendly Web server which 
>>> publishes the file via an unpredictable HTTP URL (during a 
>>> configurable period of time). The client then sends the URL it 
>>> received from the server to the MUC room. The other users click on the 
>>> URL if they are interested in downloading the file. The advantages of 
>>> this approach include:
>>> 1. It gets through any firewall.
>>> 2. The sending client only needs to transfer the file once - however 
>>> many people might receive it (simple clients).
>>> 3. People joining the room later will see the URL in the history, and 
>>> can get a copy of the file even if the sending client has gone offline.
>>> 4. The method can be supported by all clients, even clients that run 
>>> in constrained runtime environments (like Web clients).
>>> 5. It is secure as long as https: (SSL/TLS) is used (assuming the MUC 
>>> room and the HTTP server are secure - although those may be big 
>>> assumptions to make).
>>> 6. Almost every client already supports XEP-0066.
>> This is applicable to any file transfer solution other than ftp ... 
>> always host on ftp server , send the url across - practical ? Not always.
>> I do understand the reasoning - and I mention this as a possibility in 
>> one of my mails in the thread (just send the uri to conf after hosting).
>> The intention here is , how to send a file to all participants with 
>> minimum of additional infrastructure requirements.
>> For example , requiring to have a fileserver on a publically accessible 
>> internet (the users could behind different firewalls) when user wants to 
>> share a file with 3 contacts in a muc is stretching things a bit too 
>> much :-)
>> There is a requirement which comes up time and again of doing file 
>> transfer to all participants in a muc - which is a logical extension of 
>> having file transfer in a 1-1 chat.
>> The problem usually is that one of the users would not be using our 
>> client , and we run into issues. So if there is a documented way of 
>> initiating file transfer on a conference, it would be great.
>> You can use muc as a middleware for multicast - in which case , standard 
>> way to transmit binary content would be nice.
> Theoretically, wouldn't inbound streams go alright trough MUC? Well,
> except iqs to initiate it :-(. The MUC would have to understand it a
> bit, or allow sending iqs.

The problem is that , if a user wants to send a file to participants to 
a conference , and he is not using our client - there is no way of doing 
it right now.
While all other participants who are using our client will be able to. 
(same would be the case with JD's client/server I would assume ...).
Also , for public conferences , it would be good if there was a way to 
attach a file to the conference (it could go out of scope after a while 
- which is fine) such that it does not require manual parsing of 
conference messages - but more of a meta-data to the conference.
Client joins the conference and lists the files attached to the 
conference to the user (with relevant details) , and user selects which 
all to download.

>> By the way , the muc spec hints about possibility of attaching files to 
>> the conference - I did not see any proposal on this : did I miss something ?
>>>>> However, in the long term, I think we should use
>>>>> Jingle/ICE/Psuedo-TCP/S5B/IBB/UPnP/whatever-it-takes to create a p2p
>>>>> mesh that could transfer files using a BitTorrent [1] style algorithm
>>>>> wrapped in XEP-defined control channels. The MUC room would also take
>>>>> part in the torrent and take the role of the tracker and probably a 
>>>>> long
>>>>> term repository and policy enforcer.
>>> The long term might look something like that. But IMHO we've got an 
>>> excellent simple short-term solution already.
>> The short term solution is not practical except for a small subset of 
>> usecases unfortunately ... and you are expecting an 'enlightened' user 
>> (or a client which also uses webdav (and the like) to post content to 
>> public server and then publish that uri).
>> Actually , it is not really practical to expect this from most 
>> users/clients.
>> Regards,
>> Mridul
>>> - Ian

More information about the Standards mailing list