Re: XMPP client library for PHP?

> I have learned about alternatives to CJP: There's a Jabber client
> library on code.blitzaffe.com [3]. Its primary advantage over CJP is,
> according to the website, that it's event-driven and doesn't wait for a
> static time for the server to react upon requests, which makes it faster
> and more stable at the same time. I've talked to the current CJP
> maintainer and in his lack of time, he agreed that this should be the
> successor of CJP. But it fails on PHP 5 and according to the author,
> Steve Blinch, PHP 5 support has an undetermined schedule (he said this
> in January 2007). No update until today.
>   
Yeah, sorry, I've been pretty busy.  I am still maintaining the library, 
though, and I did have a PHP5-compatible version under development when 
you contacted me, but it's taken me until now to find time to get it 
done. :)  It appears to be working alright with PHP5 now though.

Contact me off-list if you want to test out a copy of the code.

Steve

File Transfer Interoperability

Re: File Transfer Interoperability

On Sun, Aug 05, 2007 at 05:49:55PM +0200, Michael Laukner wrote:
> Hi,
> I have been reading the discussions about Basic/Intermediate Client 2008
> because I was interested in file transfer interoperability. Although
> there is a standard (XEP-96) file transfer does not work properly
> within the XMPP famliy of clients.
> 
> http://www.igniterealtime.org/forum/thread.jspa?messageID=152457#152457
> http://forum.psi-im.org/thread/4174
> http://thread.gmane.org/gmane.network.jabber.standards-jig/10468
> 
> Wouldn't it be nice if file transfer worked as seamless as an e-mail
> attachment? I would love if at least the main players (recommended
> clients in jabber.org) could agree on an implementation guideline.

That surely would be nice, but standards@ currently works
on a replacement, called jingle filetransfers. The spec is still not
finished yet, and once it is out the bar for implementing filetransfer
will be set up to implementing ICE (NAT traversal technique by the
IETF, hooraay!).

I currently wonder how much energy is spent on implementing a maybe
soon (or not so soon?) outdated filetransfer method.

But I can at least agree on your observation that filetransfer doesn't
really work. I lately had someone behind some restricted firewall
and we were unable to transmit a simple small image. I thought with
IBB there is almost no way this wouldn't work (I used tkabber, but I
don't know what he used).

Maybe people think jingle with ICE will be the magical golden bullet to kill
that problem (maybe at least standards@ thinks so).

I hope that at least jingle filetransfer will be made compatible with SI
in some way (maybe there is already a protocol in the tmp queue?).

Robin

Re: File Transfer Interoperability

On Sunday 05 August 2007 8:49 am, Michael Laukner wrote:
> Hi,
> I have been reading the discussions about Basic/Intermediate Client 2008
> because I was interested in file transfer interoperability. Although
> there is a standard (XEP-96) file transfer does not work properly
> within the XMPP famliy of clients.
>
> http://www.igniterealtime.org/forum/thread.jspa?messageID=152457#152457
> http://forum.psi-im.org/thread/4174
> http://thread.gmane.org/gmane.network.jabber.standards-jig/10468
>
> Wouldn't it be nice if file transfer worked as seamless as an e-mail
> attachment? I would love if at least the main players (recommended
> clients in jabber.org) could agree on an implementation guideline.

The igniterealtime thread has a post containing compatibility test data 
between Spark, Pidgin, Psi, and Pandion.  Here is my explanation of the 
results:

Pandion doesn't support XEP-96, and Pidgin/Gaim is notoriously buggy for file 
transfer.  The problem with these two has nothing to do with a lack of an 
implementation guideline.  Someone just needs to step up and fix things.

Spark uses a special variant of XEP-96 that apparently breaks compatibility 
with every other client, most likely due to x:data ambiguity.  I'd suggest 
the Spark guys make an extension that is less prone to misinterpretation.

As far as I can tell, Psi works properly.

Keep in mind that these are not the only clients.  Gajim, iChat, and Trillian 
are also popular clients that support file transfer, and they may not have 
any of the problems described in the igniterealtime thread.  The situation 
may not be as bad as you think.

-Justin

Re: File Transfer Interoperability

In Spark we made the changes as we found XEP-0096 deficient in several respects, its support for file
transfer fail-over being one of them. A solution we hit upon for this was to allow clients to specify
multiple methods of transfer during the negotiation process; unfortunately since PSI and iChat are
strict in their interpretation of the received data from this causes file transfer to break. XEP-0096 and
the related stream XEPs are deficient in several other regards which causes a poor file transfer experience.

We have been reluctant to change this in Spark for two reasons, one being we hoped to provide a responsible
level of assurance that file transfer would not fail between Spark clients when SOCKS5 transfer failed
and two we have been told for a while now that there would be a newer method of file transfer which would
hopefully address many of the deficiencies in the current method. There was talk of updating the current
XEPs to address several of the issues we came across but they were mostly brushed aside for reason 2.

I don't know what the best solution is in this situation. We want Spark to be compatible as can be in this case
but if we were to move to strictly interpret the XEP this would cause a degradation in the file transfer
experience in Spark, as you can see it was a lose, lost situation.

Cheers,
Alex

----- Original Message -----
From: "Justin Karneges" <justin-keyword-jabber.093179 <at> affinix.com>
To: "Jabber software development list" <jdev <at> jabber.org>
Sent: Sunday, August 5, 2007 8:04:09 PM (GMT-0800) America/Los_Angeles
Subject: Re: [jdev] File Transfer Interoperability

On Sunday 05 August 2007 8:49 am, Michael Laukner wrote:
> Hi,
> I have been reading the discussions about Basic/Intermediate Client 2008
> because I was interested in file transfer interoperability. Although
> there is a standard (XEP-96) file transfer does not work properly
> within the XMPP famliy of clients.
>
> http://www.igniterealtime.org/forum/thread.jspa?messageID=152457#152457
> http://forum.psi-im.org/thread/4174
> http://thread.gmane.org/gmane.network.jabber.standards-jig/10468
>
> Wouldn't it be nice if file transfer worked as seamless as an e-mail
> attachment? I would love if at least the main players (recommended
> clients in jabber.org) could agree on an implementation guideline.

The igniterealtime thread has a post containing compatibility test data 
between Spark, Pidgin, Psi, and Pandion.  Here is my explanation of the 
results:

Pandion doesn't support XEP-96, and Pidgin/Gaim is notoriously buggy for file 
transfer.  The problem with these two has nothing to do with a lack of an 
implementation guideline.  Someone just needs to step up and fix things.

Spark uses a special variant of XEP-96 that apparently breaks compatibility 
with every other client, most likely due to x:data ambiguity.  I'd suggest 
the Spark guys make an extension that is less prone to misinterpretation.

As far as I can tell, Psi works properly.

Keep in mind that these are not the only clients.  Gajim, iChat, and Trillian 
are also popular clients that support file transfer, and they may not have 
any of the problems described in the igniterealtime thread.  The situation 
may not be as bad as you think.

-Justin

Re: File Transfer Interoperability

Alex Wenckus <alex <at> jivesoftware.com> writes:

> I don't know what the best solution is in this situation. We want
> Spark to be compatible as can be in this case but if we were to move
> to strictly interpret the XEP this would cause a degradation in the
> file transfer experience in Spark, as you can see it was a lose, lost
> situation.

I propose that you write an unofficial XEP, that describes how to use
the fallback feature, and how to advertise it through service
discovery ("http://jivesoftware.com/features/fallback" or something).
That way, a client can know in advance whether the other client
supports fallback.

--

-- 
Magnus
JID: legoscia <at> jabber.cd.chalmers.se

Re: File Transfer Interoperability

Hello

On Mon, Aug 06, 2007 at 01:18:30PM -0500, Alex Wenckus wrote:
> I don't know what the best solution is in this situation. We want Spark to be compatible as can be in this case
but if we were to move to strictly interpret the XEP this would cause a degradation in the file transfer
experience in Spark, as you can see it was a lose, lost situation.

Wouldn't a solution like:

1) Try SOCKS5 stream
2) If it fails, try negotiate IBB one? Somehow add a tag that it is
connected, so Spark client can accept it automatically and the other
clients would get it too, with little more bothering of user. (Anyway,
it would not be PSI, because it does not know IBB AFAIK).

If I'm missing something, then I'm sorry to bother and silently ignore
it…

Thanks

--

-- 
Hello, this is an extension to the famous signature virus, called spymail.
Could you please copy me into your signature and send back what you were 
doing last night between 10pm and 3am?

Michal 'vorner' Vaner

Re: File Transfer Interoperability

On 8/6/07, Magnus Henoch <mange <at> freemail.hu> wrote:
> I propose that you write an unofficial XEP, that describes how to use
> the fallback feature, and how to advertise it through service
> discovery ("http://jivesoftware.com/features/fallback" or something).
> That way, a client can know in advance whether the other client
> supports fallback.

fallback XEP++

--

-- 
- Norman Rasmussen
 - Email: norman <at> rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/

Re: File Transfer Interoperability

I do like the idea of an alternative namespace as well. The reason we went the route we did was we thought it
would be low impact from a protocol standpoint and wouldn't cause the sort of issues it did. I will work on
writing a XEP that encompasses the functionality we desire and bring it before the group.

Cheers,
Alex
----- Original Message -----
From: "Justin Karneges" <justin-keyword-jabber.093179 <at> affinix.com>
To: "Jabber software development list" <jdev <at> jabber.org>
Sent: Monday, August 6, 2007 12:41:06 PM (GMT-0800) America/Los_Angeles
Subject: Re: [jdev] File Transfer Interoperability

> > Spark uses a special variant of XEP-96 that apparently breaks
> > compatibility with every other client, most likely due to x:data
> > ambiguity.  I'd suggest the Spark guys make an extension that is less
> > prone to misinterpretation. 
>
> I don't know what the best solution is in this situation. We want Spark to
> be compatible as can be in this case but if we were to move to strictly
> interpret the XEP this would cause a degradation in the file transfer
> experience in Spark, as you can see it was a lose, lost situation.

As I wrote, maybe it is possible to make an extension that won't be 
misinterpretted.  Rather than fiddling with the x:data form, how about going 
the traditional route and adding some new namespaced elements/attributes?

We can take a time machine back to 2003:
  http://mail.jabber.org/pipermail/members/2003-August/002570.html

-Justin

Re: File Transfer Interoperability

> > Spark uses a special variant of XEP-96 that apparently breaks
> > compatibility with every other client, most likely due to x:data
> > ambiguity.  I'd suggest the Spark guys make an extension that is less
> > prone to misinterpretation. 
>
> I don't know what the best solution is in this situation. We want Spark to
> be compatible as can be in this case but if we were to move to strictly
> interpret the XEP this would cause a degradation in the file transfer
> experience in Spark, as you can see it was a lose, lost situation.

As I wrote, maybe it is possible to make an extension that won't be 
misinterpretted.  Rather than fiddling with the x:data form, how about going 
the traditional route and adding some new namespaced elements/attributes?

We can take a time machine back to 2003:
  http://mail.jabber.org/pipermail/members/2003-August/002570.html

-Justin