2015-06-28 20:36 GMT+02:00 Christian Schudt <christian.sch...@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. - Daniel
