[Standards-JIG] File transfer in MUC

Mridul mridul at sun.com
Sat Oct 14 18:59:52 UTC 2006


Hi,

  The list of requirements below sound interesting.
I think we should write something down and propose it too :-)
I will contact you off the list about it.

Regards,
Mridul

JD Conley wrote:
>> I was thinking of a simple extension to this - if a file gets attached
>> to the public muc (in some way) , it could get archived , picked up by
>> later joinee's , etc too : not just current participants.
>> I was thinking along these lines since it is alluded to in the muc
>>     
> spec
>   
>> and thought it might be a more generic solution.
>> The current problem we have is - how can the client send a file to all
>> participants of a muc : once this is solved , other requirements might
>> come in later :-)
>>     
>
> Sounds good. We just need to make sure we don't preclude requirements
> other than file transfer.
>
> Off the top of my head I can think of a few great uses of streaming
> binary data to MUC participants.
> 1) File Transfer
> 2) Hello[2]?
> 3) Groove[1], anyone?
> 4) Voice Conference
> 5) Video Conference
> 6) Real Time Gaming
> 7) Avatars (ok, maybe a stretch)
> 8) 3D Modeling Collaboration
>
> We need to facilitate the delivery of all these types of data both
> one-to-one, one-to-many, many-to-many and also provide the ability for
> it be persistent - maybe with http even. As Mridul mentions we already
> have the streaming specs in place to make this happen. Either Jingle or
> Bytestreams would be fine with me (as either could be extended for a p2p
> mesh with a new profile). This could easily be something announced in
> disco features for the conference component and conference room and
> configurable through the x:data form.
>
> This should be at least one new XEP on top of existing MUC for
> establishing the stream. Maybe Mridul and I should stop whining and
> write it? :)
>
> -JD
>
> [1] http://www.groove.net
> [2] http://www.hello.com 
>   




More information about the Standards mailing list