Re: [Standards] Request HTTP upload slots over XMPP
On 30/06/15 19:45, Peter Waher wrote: > > Hello Daniel > > > > You could use XEP-0332, HTTP over XMPP, to do this. To upload content, > simply perform a PUT, and you can then retrieve it using a normal GET. > > http://xmpp.org/extensions/xep-0332.html#PUT > > > > If content is small, you can do the transfer in the same request. > Otherwise, chunked service can be used, or integration with sipub, ibb > and/or jingle as well, depending on capabilities. > So, you're suggesting an in-band transfer mechanism for out-of-band data transfers? That sounds a bit wasteful to me. By the way, how are updates to 332 progressing? Edwin
Re: [Standards] Request HTTP upload slots over XMPP
Hello Daniel You could use XEP-0332, HTTP over XMPP, to do this. To upload content, simply perform a PUT, and you can then retrieve it using a normal GET. http://xmpp.org/extensions/xep-0332.html#PUT If content is small, you can do the transfer in the same request. Otherwise, chunked service can be used, or integration with sipub, ibb and/or jingle as well, depending on capabilities. Best regards, Peter Waher Från: Daniel Gultsch [mailto:dan...@gultsch.de] Skickat: den 28 juni 2015 09:26 Till: XMPP Standards Ämne: [Standards] Request HTTP upload slots over XMPP Hi current file transfer techniques in XMPP all share the same downside. They are P2P and thus don't work with Carbons and MUCs. The synchronous nature of P2P protocols also doesn't play nicely with MAM. Uploading files manually to an HTTP server and sharing the link has been an workaround for this for a long time now. (This has also been used in the good old IRC age) While users have a variety of services to choose from (imgur, mediacrush, self hosted OwnCloud, Google Drive, ...) the major downside of this is that an xmpp client can not automate this process since the different services don't share a common api. Furthermore using a third party service might require the user to enter additional credentials on top of the XMPP credentials. Thus it would make perfect sense to have the xmpp provider also provide a way to upload files to an HTTP server. Today I want to introduce a simple protocol for requesting what I call 'HTTP upload slots'. An HTTP upload slot is basically a tuple of a PUT and a GET URL. The user requests a slot from a component (most commonly running on the users servers and discoverable by disco items) providing a desired file name and a file size. The component does some checking on the data (quota, max file size, authorization) and provides the user with a PUT and a GET url which both are unique. (long random string in path) Examples out: a_picture.jpg in: https://download.domain.tld/a_long_randomly_generated_path/a_picture.jpg https://upload.domain.tld/a_long_randomly_generated_path/a_picture.jpg Note that the get and put host are not the same. This allows for the files to (optionally) be served over some standard HTTP server /or even a CDN. Also note that the user provided file name is reflected in the GET url as well this way allowing the recipient of that URL to see the original file name. (However this is the something a sane component should do and is not required) I would like to get some comments before I actually put this down into a XEP. For those interested here: https://github.com/siacs/HttpUploadComponent is a sample python implementation of such a component. And here is a branch for Conversations that can talk to that component. https://github.com/siacs/Conversations/tree/feature/http_upload cheers Daniel
Re: [Standards] XEP-0322: EXI for constrained processing environments
Hello Rick
Thanks for your input. For small devices, that do not wish to (or cannot)
perform a dynamic handshake, there's the concept of quick configurations
(§2.6). With a quick configuration ID, the entire setup is predefined. It
can be defined, either in-band using a normal handshake, as described
earlier, perhaps by a more powerful device, or out-of-band, by manual
configuration of the server.
Best regards,
Peter Waher
-Ursprungligt meddelande-
Från: Rick van Rein [mailto:r...@openfortress.nl]
Skickat: den 26 juni 2015 01:42
Till: XMPP Standards
Ämne: [Standards] XEP-0322: EXI for constrained processing environments
Hello,
I was happy to run into XEP-0322, explaining a path of integration for the
compact XML representation of EXI.
The fully specified path assumes starting off with fullblown XML and then
switching to EXI; this is a scenario that would work when the viewpoint is
saving bandwidth. Another usecase, where EXI serves the relative simplicity
of a client, is not really dealt with under the usual clarity.
I am thinking of constrained processing environments, such as clients on
microcontrollers. These may want to use EXI to avoid having to deal with
the full XML notation, and they would most certainly not be serviced if they
have to go through an initial handshake based on XML.
Although 2.4 gives some ideas and possibilities, its style sounds
informative ("ex." and "e.g.") rather than normative, which means that there
is non real certainty to be drawn. I am writing to emphasise that this
should IMHO be cleared up before finalising this XEP.
As for the EXI cookie, is it an idea to use a processing instruction and/or
XML declaration that would be sent to the server? That would be in line
with common XML syntax without adding the burden of XML parsing onto the
(constrained) client. A few forms could be used, and in all honesty, may be
better standardised as part of EXI than as part of
XEP-0322 because it would occur everywhere EXI is used:
(illegal 1.0 syntax)
(illegal 1.0 syntax)
(illegal 1.0 syntax)
(breaks with 1.0 requirements)
(after -- upon recognition, respond
with the same string, would otherwise ignored?)
Ref: http://www.w3.org/TR/REC-xml/#sec-pi and
http://www.w3.org/TR/REC-xml/#sec-prolog-dtd
This approach would save from specifying another port, and it would be easy
to send/process in a constrained environment. Adding NS negotiation might
be possible along the same lines, but would already be more complex. Still,
not having to build an XML processor to be able to switch to EXI seems like
a really good usecase to me.
I hope this is useful!
Cheers,
-Rick
Re: [Standards] XEP-0322: EXI for constrained processing environments
Hi Rick We also believe that EXI is very useful in restricted environments. That said, w.r.t. this use case the XEP-0322 might be further improved. We shared already our ideas in the following thread [1][2]. > The fully specified path assumes starting off with fullblown XML and > then switching to EXI; this is a scenario that would work when the > viewpoint is saving bandwidth. Another usecase, where EXI serves the > relative simplicity of a client, is not really dealt with under the > usual clarity. I think you gave yourself the answer in the latter part of your mail mentioning that with a dedicated port one can start using EXI right-away. Is this approach not working for you? > As for the EXI cookie, is it an idea to use a processing instruction > and/or XML declaration that would be sent to the server? Please correct me if I am wrong but I think this has nothing to do with processing instructions. The EXI Cookie is an optional part of the EXI stream. In fact it is nothing more than a 4 byte "magic cookie" that serves to identify whether a stream is XML or EXI. Thanks, -- Daniel [1] http://mail.jabber.org/pipermail/standards/2014-October/029228.html [2] http://mail.jabber.org/pipermail/standards/2014-October/029254.html
