[Standards] File Repository and Sharing updates (Re: meeting minutes, 2007-02-26)
stpeter at jabber.org
Mon Mar 5 22:39:35 UTC 2007
Nick Parker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> Here are the main points I've extracted from that paragraph:
Thanks for following up. It was late in 3 days of meetings (and pub
discussion) when we got to those items, so we may not have been fully
> 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.
Yes the queueing didn't seem compelling to me, but then I don't know
what use cases you envision.
Now, it is possible that SI-pub doesn't play well with transfers that
don't use SI (think Jingle), so we need to think about that.
> 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?
Google Talk uses Jingle for File Transfer. Some documentation here:
We haven't published that yet officially, since the file transfer
landscape is a bit unsettled right now. :(
> 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.
Yes that seems reasonable.
> 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. :)
I think the concern is that we're "forcing" Jabber clients to support
all sorts of non-XMPP protocol stacks. However, I realize that you may
be thinking about building this into something other than stock Jabber
clients. If so, it would be good to specify that in your proposal.
Thanks for your patience and for the continued modifications. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards