I vote for not moving towards supporting :4. There isn't a compelling
reason to do it. So it is better to wait until (or if) there features
are supported in the next version or in some other XEP.
On 20/06/15 16:13, Daniel Gultsch wrote:
2015-06-20 21:59 GMT+02:00 Yann Leboulanger
Hi
current file transfer techniques in XMPP all share the same downside. They
are P2P and thus don't work with Carbons and MUCs. The synchronous nature
of P2P protocols also doesn't play nicely with MAM.
Uploading files manually to an HTTP server and sharing the link has been an
workaround for
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
https://xkcd.com/927/
On 28 June 2015 at 21:43, Daniel Gultsch dan...@gultsch.de wrote:
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)
Hi,
Letting the component act as a Jingle File Transfer receiver was my original
idea as well. However if you try to find any jingle ft implementations you'll
see that there basically aren't any. (To my knowledge there is Gajim,
Conversations and Swift (beta) and Swift is currently
Hi,
I agree that XMPP is lacking such a specification („MUC File Transfer“,
„Offline File Transfer“).
Maybe it’s even better, if the client and server could negotiate the transport
method first, so that the client could choose between „HTTP Upload“, SOCKS 5
Upload (XEP-0065)“ or „In-Band
Hi
I've been developing this idea since almost a year now. Never got around to
actually write some code until now.
2015-06-28 19:16 GMT+02:00 Christian Schudt christian.sch...@gmx.de:
Hi,
I agree that XMPP is lacking such a specification („MUC File Transfer“,
„Offline File Transfer“).
