> On Aug 13, 2015, at 7:11 AM, Kevin Smith <[email protected]> wrote: > >> 2) Accept as experimental? http://xmpp.org/extensions/inbox/http-upload.html >> >> All to vote on list > > I’m ever so marginally +1 on this. I am very uncomfortable with introducing > another file transfer negotiation mechanism, and I believe this should be > done with Jingle (for the negotiation), which has many advantages (the server > could offer HTTP upload as well as other mechanisms, etc.), so this does meet > one of my criteria for blocking a protoXEP.
So, based on discussion in the other thread about the HTTP Upload proposal, I wrote up what a Jingle transport based on HTTP transfers could look like: http://legastero.github.io/customxeps/extensions/http-transport.html There were a few things I learned in the process: 1. While it would be possible to use this to negotiate uploading a file to a server, there is not yet any Jingle mechanism telling the server that it should in turn expose the shared content with others (COLIBRI kinda does this, but that's just for RTP streams and is still outside of the Jingle negotiation process). We would need to do something like expand JinglePub (XEP-0358) so that including a <jinglepub /> element in the session-initiate signals that we want the session content to be available for others to request. While I think this is desirable as a long term and more general solution, it gets further from the simplicity of the original proposal here. 2. The HTTP upload proposal is more accurately discussed in term of storage space and URI provisioning, not file transfer directly. For example, using the Jingle HTTP transport above, I could request a storage slot and signal the details of that slot to another client, requesting that other client to upload a particular file to my file server. That is powerful, and it requires a URI provisioning process outside of Jingle. We've had a similar situation for Jingle RTP with COLIBRI (XEP-0340). Any client-client transfer situation will end up with one of the clients needing to ask *something* to provision URIs. (puts on council voting hat) All of that said, I am +1 on a modified form of HTTP-Upload (Sam and Mickaël had some good improvements that should be reviewed and incorporated). - Lance
smime.p7s
Description: S/MIME cryptographic signature
