[Standards-JIG] File transfer in MUC

Ian Paterson ian.paterson at clientside.co.uk
Sat Oct 14 00:03:34 UTC 2006


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.

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

- Ian




More information about the Standards mailing list