[Standards] File Repository and Sharing updates (Re: meeting minutes, 2007-02-26)

Nick Parker nickp at bu.edu
Fri Mar 2 21:23:25 UTC 2007

Hash: SHA1

> 5. ProtoXEP: File Repository and Sharing
> Accept as a XEP?
> Direct proposal author to investigate and compare his approach to
> XEP-0137 and explore how to integrate Jingle as the transfer method (the
> Council found it somewhat unhelpful to point clients at such a large
> number of mirroring technologies). Publication may depend on settling
> preferred XMPP file transfer methods (discussed but not settled at XMPP
> Summit).

Here are the main points I've extracted from that paragraph:

1) Using XEP-0137 (SI)

I'm surprised I didn't see this one already, as it pretty much solves
the same problem as my little custom request system, except far more
I'm planning on entirely replacing my custom file requests with SI. In
other words, I will be removing the "jabber" mirror type and replacing
it with a new "si" mirror type which holds the same information as
0137's sipub element.

One downside to this switch is the removal of queueing support, does
anyone think this would be a major loss? If someone wanted queueing,
they could just have the sender return a normal text message which says
"Your file is in the queue and will be sent shortly (est 5 minutes)", or
something to that effect. The current queueing system seems like overkill.

2) Using Jingle for sending files

I've skimmed the Jingle spec a couple times, but haven't seen anything
yet which explicitly covers file transfers. Is something for this coming
soon, or have I just been looking in the wrong places? Assuming there's
something out there for sending files over Jingle, it seems like the
best thing to do would be simply adding a "jingle" mirror type which
holds the info for requesting the file. If, instead, Jingle file
transfers can be requested with SI, then it can simply be listed as
another SI mirror with a different 'profile' field.

3) Large number of mirror types

"jabber" - Planning to replace this with SI (see #1), as my custom
protocol pretty much did the same thing (except less elegantly). I'd see
SI+FileTransfer (and/or SI+Jingle?) being the common "built-in" file
transfer system, with the other protocols (listed below) being more
intended for situations where someone has an existing web/file server
set up and they want to put an announcement system in front of it, which
I could see as being very useful in a large number of cases.

http,https,ftp,sftp(ssh) - Worth keeping. These protocols are all quite
ubiquitous, and I could easily them being used for all kinds of things.
These protocols would also take minimal effort to include, as the jabber
client could just load the user's default browser for the given
protocol, and let that deal with the file retrieval (and/or display). In
other words: I think these are too important to prune, as they are both
widely useful and widely used. Can't hurt to at least provide
definitions for them.

smb - Sorta on the fence with this one, would it be particularly useful?
If so, should other similar protocols (AFS, NFS, etc) be considered as
well? Like the above, the jabber client could just load an external
program which points to the given location, or even just say "Pubsub
server says that file x on server y has been updated!"

irc-dcc - Gonna remove this. It would be very complicated to implement
in any kind of automated form, and in hindsight I don't see it being
very useful anyway, as anyone who distributes files over IRC is probably
already comfortable with using IRC clients to do it. :)
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list