[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  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
> >>>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
> >- 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
Size: 189 bytes
Desc: not available
More information about the Standards