Re: [Standards] XEP-0234 Jingle File Transfer 0.16

The reasoning behind creating a FT:4 was to leverage the core semantics of Jingle versus continuing to reinvent them inside of FT to solve some of the remaining open items in the FT:3 spec. (The idea here being that a general Jingle session management implementation should have a well lit path

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

While we're on the subject, is there any benefit to having a reestablish mechanism in a more general sense? I'm thinking about the number of times I tell colleagues that I'll call them right back - would we save much effort in negotiation if we chose to repeat a previous session rather than create

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 7/13/15 5:12 PM, Emmanuel Gil Peyrot wrote: On Mon, Jul 13, 2015 at 10:41:28PM +0200, Yann Leboulanger wrote: But the way things are done is a bit strange. The feature was available and working. Removing a few lines in a XEP makes features no more available and another depending XEP no more i

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 07/13/2015 09:37 PM, Tobias Markmann wrote: On Mon, Jul 13, 2015 at 9:30 PM, Yann Leboulanger > wrote: As there is no other answer, I guess nobody is interested in this topic. Sad but I'll stay with :3 then. Well.. there is http://xmpp.org/extensions/in

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On Mon, Jul 13, 2015 at 9:30 PM, Yann Leboulanger wrote: > As there is no other answer, I guess nobody is interested in this topic. > Sad but I'll stay with :3 then. > Well.. there is http://xmpp.org/extensions/inbox/jingle-pub.html Would this cover your use case and would there be interest seei

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 06/21/2015 03:56 PM, Tobias Markmann wrote: On Sat, Jun 20, 2015 at 2:08 PM, Yann Leboulanger > wrote: I just read the version 0.16 of Jingle File Transfer XEP, and saw that you removed the flow. Just to mention that it is used in Gajim to re-request t

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

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

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On Sat, Jun 20, 2015 at 2:08 PM, Yann Leboulanger wrote: > I just read the version 0.16 of Jingle File Transfer XEP, and saw that > you removed the flow. > Just to mention that it is used in Gajim to re-request the file at the > end of a tranfer when hash was wrong. > Does that happen without u

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

2015-06-20 21:59 GMT+02:00 Yann Leboulanger : > That will also break compatibility with clients that supports only :3 > namespace, but currently we don't work with clients that have :4 > namespace implemented. implementing several version of a protocol is > quite complexe. > Thats basically the r

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 06/20/2015 09:41 PM, Daniel Gultsch wrote: > out of curiosity does this mean you are working on implementing jingle > file transfer 0.16 in gajim? > I was looking at it, but this would cause a regression in 2 of our features: ability to re-request a file in hash is wrong and our file sharing pl

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

out of curiosity does this mean you are working on implementing jingle file transfer 0.16 in gajim? 2015-06-20 14:08 GMT+02:00 Yann Leboulanger : > Hi all, > > I just read the version 0.16 of Jingle File Transfer XEP, and saw that > you removed the flow. > Just to mention that it is used in Gaji

[Standards] XEP-0234 Jingle File Transfer 0.16

Hi all, I just read the version 0.16 of Jingle File Transfer XEP, and saw that you removed the flow. Just to mention that it is used in Gajim to re-request the file at the end of a tranfer when hash was wrong. I don't think it's a good thing to removed a feature without a replacement, that's not