[Standards] Request HTTP upload slots over XMPP
daniel at gultsch.de
Sun Jun 28 20:43:33 UTC 2015
2015-06-28 20:36 GMT+02:00 Christian Schudt <christian.schudt at gmx.de>:
> Jingle File Transfer might be rarely implemented currently, because it is
> still in Experimental status. But a new (experimental) protocol (yet
> another one for file transfer), which will probably evolve as well, would
> certainly be implemented far less than Jingle FT and add more confusion to
> the question „how does file transfer work in XMPP“.
I don't think the lack of implementation of jingle and jingle ft is due to
the 'experimental status' but due to the complexity. I think people try to
implement a general stack for all jingle applications and then get stuck
because it is just so much work. (Like I said I was trying to do exactly
this and was researching libraries that come with jingle support and I
found many unfinished jingle implementations across all sort of libraries
> > I don't see any upside of sticking with Jingle besides that it is
> somewhat the "XMPP-way“.
> - Reuse of existing protocols
> - Less complexity for developers who already have to do a stretch to
> support the different file transfer protocols under a general API.
> - Different transports can be used for upload. Not only HTTP but also
> SOCKS5 and IBB.
> - Jingle (File Transfer) semantics can be reused, e.g. to cancel or reject
> a file upload or to communicate the hash, the file name, the file size,
> I don’t know if Jingle (FT) is really suitable for the use case, but at a
> first glance it feels like the most obvious approach.
Jingle FT would suitable (It doesn't provide an easy way to communicate the
GET-URL back to the sender but that could for example be solved by some
convention thing in the service discovery like always use a fixed prefix
for the GET urls followed by a file name provided by the user)
I fully agree with you that having a jingle based approach maybe including
a HTTP Transport method would be the ideal and perfect solution for this.
However I doubt that this will happen any time soon. Multiple vendors are
already moving to their own niche solutions. (Kontalk is using a similar
approach. One XMPP based social network (I forgot which one) is doing
something similar. Many users are already doing exactly the same thing but
manually (upload files to owncloud and sharing the link))
If we look at this from a business point of view using HTTP upload is imho
the most cost effective way of doing this. If someone comes to me and says:
"hey we want an xmpp based instant messenger with the ability to send files
to groups and multiple instances and we don't really care about standards
just make this happen" I would always go with the HTTP based solution.
The question is do we wait another 10 years and try to come up with a
perfect jingle standard and have people that need a solution now come up
with their own incompatible custom extensions or do we provide those people
with a very small XEP that is easily implemented and can serve as a
temporary solution until the perfect solution is ready.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards