https://xkcd.com/927/ On 28 June 2015 at 21:43, Daniel Gultsch <[email protected]> wrote:
> > > 2015-06-28 20:36 GMT+02:00 Christian Schudt <[email protected]>: > >> 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.
