Re: [Standards] Proposed XMPP Extension: HTTP File Upload

[Mickaël Rémond]

Hello Philipp,

On 30 Jul 2015, at 20:12, Philipp Hancke wrote:


HTTP Upload is just another transport as far as jingle is concerned.
So you would send your session-initiate with the XEP-0234 description 
(instead of reinventing this in example 5) along with an empty 
 qualified by 
urn:xmpp:jingle:http-transport-something-something.


In the session-accept you would get a transport element telling you 
where to put this. This would basically be the put url.


After the transfer is done, the receiver sends a session-info telling 
you the location where to get the file (this is the only design change 
compared to the current approach but I think it allows the service to 
process things and decouple things)


I think this wouldn't change the semantics of the proposal much, just 
how things are done on the wire.


In my mind, Jingle set of protocols are for live streams and they have 
the following characteristics:
- You negotiate either an "infinite" stream (for voice / video calls) or 
more limited streams.
- Negotiation happens between sending and receiving party. It means they 
need to be both online at the same time.
- They can agree on any transport they like, including HTTP. We have 
developed a streaming HTTP proxy to allow upload and download at the 
same time before the file is fully received. However, the semantic in 
that case is still "live" transfer.


The protocol proposed by Daniel is asynchronous by nature. It is more 
about file sharing than transfer actually.


I truly think both approach have their use and they do not overlap:
- Jingle for live negotiation if binary stream transfer. Use is mostly 
for live conferencing systems for example.
- HTTP file slot approach for asynchronous sharing. Use is mostly for 
mobile client that have, by nature, very intermittent connection.


I hope clearly specialising both XEP will make developers of both types 
of apps happy.


--
Mickaël Rémond
 http://www.process-one.net

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

[Mickaël Rémond]

Hello Sam,

On 1 Aug 2015, at 21:51, Sam Whited wrote:


If you're going to try and implement a version of your spec with
headers and test it against a particular service, I recommend AWS S3
(I've been using it as an example as it's probably the most common
large file storage solution [citation needed]).


Actually, the first spec we published is already used for an Amazon S3 
backend in production.


--
Mickaël Rémond
 http://www.process-one.net

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

[Mickaël Rémond]

Hello,

We had a try at changing a bit our approach for HTTP-based file transfer 
to support use cases, pointed out by Sam and Daniel.


The result is here:
https://github.com/processone/ejabberd-saas-docs/blob/master/xmpp-specs/http-filetransfer/http-filetransfer.md

What we changed is:

- Ability to have permanent download URLs that do not require the client 
to know about the protocol. When URL is permanent (or before the 
download URL expires) client is not forced to request a download URL 
from the file id.


- Added ability for the server to pass headers along with upload URL. 
The client may need to use those HTTP headers to be allowed to upload 
the file.


Please, let me know if this is helpful.

We have something that we have left pending, waiting for your feedback: 
the hash for now is a binary md5 as this is the one supported by Amazon 
S3. However, other services may use other type of hash or no hash at 
all. What bothered me is that User avatar use SHA-1 as id. Some service 
may use the same hash for consistency. Some service may not require any 
hash at all or just use file size as a basic check.

We may need a data form to accommodate that flexibility.

Do you think it is worth it ?

--
Mickaël Rémond
 http://www.process-one.net