[Standards-JIG] File transfer in MUC
ian.paterson at clientside.co.uk
Sat Oct 14 00:03:34 UTC 2006
> 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  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.
More information about the Standards