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
<transport/> 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
