[Standards-JIG] File transfer in MUC

Mridul mridul at sun.com
Fri Oct 13 20:04:14 UTC 2006


Hi,

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

I will jot down a couple below that I can think of : which will work 
right now , with potential problems with each.
Also have a proposal below - but supporting that will be more of a 
protocol extension since clients/servers do not support that as of now.

1) Client asks the user for list of all full jid's in some list - user 
provides all that he knows of : client initiates 1-1 transfer with each 
user to ship the file.
Adv :
a) Direct extension of the basic file transfer.
Disadv that I can think of :
a) Cumbersome to provide all jid's - may not be available to user. 
Cannot transfer to all participants in case user does not know the jid's 
of all.
b) Very heavy from a client point of view - 'n' number of 1-1 file 
transfers !
c) A late joinee of the conference does not know about this file - and 
cannot even find out about it. The file transfered using muc info is 
totally transparent to muc.


2) Add support to the muc component such that - user sends file to muc , 
muc multicasts this to the participants : using file transfer.
Adv :
a) Single transfer from sender to server.
b) Will be able to broadcast to all participants.
c) Will be able to add acl's of who can and cant send/receive files as 
an impl detail of the muc.
d) It might be possible to hack this file into the muc archives such 
that a subsequent clients could use "some way" to fetch previously 
transfered files.
Disadv :
a) Not really supported - but this might not be too tough to add I guess.
b) Server/component will need to support a pretty wide range of file 
transfer mechanism's to be able to receive and transmit files from/to 
all sorts of clients : and there might be deployment considerations 
which prevent some of them from being usable (firewall prevents oob , etc).


The above too would not be too intrusive to add - but from a usability 
and protocol point of view , they are not very 'good'.


Another alternatives I was thinking of was to leverage pubsub for this 
purpose (just brainstorming , not thought it through) .
a) User creates a pubsub node for the file and sends that to the muc.
muc persists the pubsub node info (for subsequent clients) , broadcasts 
this to current participants and all clients use that pubsub node to 
retrieve the content.
b) User creates a pubsub node , sends to muc component.
Component retrieves the file , persists it locally "some place" (in case 
the client exposed uri is a transient : maybe this can be communicated 
in some way) , and then uses the conference's pubsub node to push 
availability of new file (this node created for each conference (maybe 
on demand) for the purpose of file transfer).
(Since I cannot push binary data to a pubsub node (?) - we have the uri 
indirection above).


I am sure others might have alternate implementations and ideas , would 
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.


Thanks,
Mridul



More information about the Standards mailing list