[Standards] Request HTTP upload slots over XMPP
dave at cridland.net
Sun Jun 28 21:21:31 UTC 2015
On 28 June 2015 at 21:43, Daniel Gultsch <daniel at gultsch.de> wrote:
> 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
> and languages)
>> > 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, etc...
>> 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.
There's two interesting cases. First, you need to send someone a URL for
where to get the file.
Second, you need to put the file there.
A mechanism for denoting files available over HTTP seems pretty
straightforward, and since I'm not sure how many server operators really
want to get into the Dropbox/Box/Adrive/GoogleDrive/OneDrive/etc market,
maybe the upload isn't something you need to do over XMPP at all.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards