[Standards-JIG] File transfer in MUC
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Fri Oct 13 20:58:02 UTC 2006
On Fri, Oct 13, 2006 at 01:52:58PM -0700, JD Conley wrote:
> > If I want to transfer a file to all participants in a muc , what
> > approach is the client/server supposed to take ?
> > If there is a solution for this already , please point me to it - I
> > could not find anything ...
> There isn't anything out there.
> > I am sure others might have alternate implementations and ideas ,
> > be great to know how you solve this problem.
> > We support both (1) and (2) above with our client and server (based on
> > which version of client/server you talk to , and a bunch of config
> > options) - but would be great if there was some standard directive for
> > this usecase.
> Your (1) and (2) are both perfectly good implementations. In fact you
> may see an incarnation of (2) in an upcoming release of ours (perhaps we
> should chat about that later).
> 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.
My idea is that there is tcp for files and building another tcp inside
app is wrong (at last, duplication of work, and your tcp will probably
not be so good, it too quite some time to develop decent flow control,
and you do not have access to flags like don't fragment in the app).
And, if you want to imitate torrent in the way who downloads anything,
shares it to others from that moments, it has two big problems:
a) difficult to implement
b) half the net admins will forbid such application from their networks.
p2p transport is usually OK, but sharing for others if not explicitly
set by user is not.
You can't have everything... where would you put it?
-- Steven Wright
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