[Standards-JIG] File transfer in MUC

Michal 'vorner' Vaner michal.vaner at kdemail.net
Sat Oct 14 06:14:17 UTC 2006

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.

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

This email has not been checked by an antivirus system.
No virus found.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061014/b1e2274e/attachment.sig>

More information about the Standards mailing list