[Standards-JIG] File sharing JEP

Peter Saint-Andre stpeter at jabber.org
Fri Apr 7 16:34:48 UTC 2006

Hash: SHA1

/me bites the bullet

IMHO the long-term solution is to do all out-of-band media exchange
using Jingle. That would include file transfer / file sharing.

My reasoning is as follows:

1. It's not good to have two ways to do similar things, since it makes
coding clients harder. The Stream Initiation (SI) framework is quite
similar in concept to Jingle, though IMHO not as flexible.

2. We never figured out a good way to do anything but file transfer
(such as voice and video) using SI. Or at least I never figured it out.

3. I think Jingle gives us a more flexible approach than SI (voice,
video, etc.), thus enabling clients to support only one framework for
all media exchange.

4. It's possible we could define a Jingle transport method for SOCKS5
bytestreams, thus re-using JEP-0065 (though I haven't worked out the
details yet).

5. File transfer / file sharing over Jingle would be defined in such a
way that it enables the transfer of multiple files, rather than just one
file. Thus no need for something like JEP-0105, which never took off for
a variety of reasons.

6. Jingle should include all the retry semantics that people want to add
to JEP-0096 (if not, we need to define how that would work).

Or so it seems to me right now.


Hal Rottenberg wrote:
> Are you saying toss all other file transfer and negotiation JEPs in
> favor of Jingle?  Or are there multiple use cases here?
> On 4/6/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> IMHO it might be best to do this using Jingle. So we'd write a Jingle
> media description format for file sharing and re-use all the emerging
> Jingle semantics for negotiation and setup. You could offer that service
> only to people you trust (in a certain roster group or whatever). I've
> been meaning to work on this but haven't gotten to it yet.
> Peter
> François Beretti wrote:
>>>> Hi,
>>>> First, a few warnings:
>>>> I am new to XMPP and new to this list, I am just a normal Jabber user.
>>>> So I probably made several mistakes or misunderstandings on Jabber,
>>>> the JEPs, etc.
>>>> I am not english, so I probably made several english errors.
>>>> I hope I dont make you waste your time, don't hesitate to give me just
>>>> a link to an answer or something
>>>> So I start: I would really like to have file sharing features added to
>>>> my Jabber client, who seems to be extensible.
>>>> I have tried file sharing software like QNext ( http://www.qnext.com/
>>>> ), who let the user create shares, and give access on them to members
>>>> or groups of members of its contact list. Depending on the type of
>>>> share the actions are different : a file share allow the contacts to
>>>> download the files, a music share allow the contacts to listen to the
>>>> music using streaming, and a photo share allow the contacts to view
>>>> the photos in a graphical gallery.
>>>> But for the moment, a simple file sharing can be enough.
>>>> For this I found the JEP 135:
>>>> http://www.jabber.org/jeps/jep-0135.html
>>>> on which a few remarks have been made on this list (I searched the
>>>> archives with gmame):
>>>>  - due to JEP 105, a file information doesn't contain the file type
>>>> when retrieved in a list of files, which force the contact to retrieve
>>>> individual file information to know it, which is a waste of time and
>>>> ressources
>>>>  - JEP 135 does not allow to specify access control lists when
>>>> publishing a share
>>>> Then, as a last remark, the jep was deferred due to its inactivity.
>>>> As I would like to implement it, I would like to know what it lacks,
>>>> and make my own remarks.
>>>> I am not sure to understand the file transfer part. Can a media file
>>>> be streamed over the network ?
>>>> Moreover, in the same way some people want to add a type for a file, I
>>>> would like to add a type for a node of the tree, to define share
>>>> types:
>>>>  - file share
>>>>  - photo share
>>>>  - streamed media share (music, video..)
>>>> That makes me wonder: after the JEP is approved, if someone want to
>>>> add a share type, it can't modify the JEP, since it is approved. Can
>>>> there be a JEP extension ? Or does it mean such a restricted type list
>>>> is not accepted in a JEP, in order not to restrict future use ?
>>>> As the type problem is actually in the JEP 105:
>>>> http://www.jabber.org/jeps/jep-0105.html
>>>> which defines a tree transfer, I studied this JEP, that is also deferred.
>>>> The first lack I see in it seems to be the ability to specify a type,
>>>> for both a file and a directory. But we could also want to add
>>>> information like the size of a file, or the rights you have on the
>>>> directory (read or write).
>>>> As JEP 105 is deferred, is it possible to modify it ?
>>>> For the problem of access control, I don't think we should publish the
>>>> access control list of each share, so I think it has not its place in
>>>> the data. But maybe I forget a big thing...
>>>> One problem I see is that the shares and the access control are
>>>> configured on the local machine, and are not present if you connect
>>>> from somewhere else. As most shares are local files it shouldn't be a
>>>> problem, but JEP 135 describes a share stored on a file server while
>>>> you connect from another computer. So for this type of shares, access
>>>> control and shares configuration should be stored in another place
>>>> than the computer. I don't know what is possible with Jabber on this
>>>> point.
>>>> But maybe I should start trying to implement all this in a plugin for
>>>> my Jabber client, which means for me starting learning python and
>>>> writing plugins for Gajim (I don't even know if its possible)
>>>> Thank you :)
>>>> Best regards,
>>>> François Beretti
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060407/9b735164/attachment.bin>

More information about the Standards mailing list