[Standards-JIG] File transfer in MUC
Mridul
mridul at sun.com
Fri Oct 13 15:04:14 CDT 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-JIG
mailing list