On Mon, Jan 23, 2006 at 12:19:54PM +1100, James Bunton wrote:
> That means just about any Jabber client that supports file transfers
> should be able to send/receive to MSN contacts.
To make sending work in iChat, I had to apply the attached patch (while
a 'mode' attribute is required by JEP-0065 on streamhost offers, iChat
apparently doesn't set this). With this patch, file sending (and
receiving) is working great!
I've only found a minor issue with file sending. If the connection
between the Jabber client and the transport is faster than the
connection between the transport and the MSN Messenger client, the
progress bars in the Jabber client and the MSN Messenger client don't
match (the progress bar in the Jabber client will run faster) - so as a
Jabber user I don't know when the transfer is actually completed. Right
now the transport will receive data from the Jabber client as fast as it
can, and buffer the data (the entire file being sent) in memory - this
leads to quite a large use of memory. It would be nice if the transport
would only buffer a small amount of data and throttle the Jabber client
sending data.
I guess the same issue is also present when receiving files and the
connection between the MSN Messenger client and the transport is faster
than the connection between the transport and the Jabber client.
Best regards,
Lars
-------------- next part --------------
Index: misciq.py
===================================================================
--- misciq.py (revision 99)
+++ misciq.py (working copy)
@@ -616,7 +616,7 @@
froj = jid.intern(el.getAttribute("from"))
query = el.query
- if not (query and query.getAttribute("mode") == "tcp"):
+ if not (query and query.getAttribute("mode", "tcp") == "tcp"):
return errOut()
sid = query.getAttribute("sid")
consumer = self.sessions.pop((froj.full(), sid), None)
From [EMAIL PROTECTED] Mon Jan 23 15:35:14 2006
From: [EMAIL PROTECTED] (Stian B. Barmen)
Date: Mon Jan 23 15:35:33 2006
Subject: [py-transports] PyMSNt file transfer UP!
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
James Bunton skrev:
> Receiving files should be working again now.
>
> ---
>
Gajim looks for a resource for sending files and therefor disables the
send file option. The JEP does not require this but an example is
presented. Could this feature be included? This way a client would be
able to check for FT support in the transport.
Best regards
Stian B. Barmen
From [EMAIL PROTECTED] Mon Jan 23 15:58:10 2006
From: [EMAIL PROTECTED] (Jorge Merlino)
Date: Mon Jan 23 15:58:34 2006
Subject: [py-transports] Possible presence bug in PyMSNt
Message-ID: <[EMAIL PROTECTED]>
Hello,
I'm using PyMSNt 0.10.3 and I have observed the following problem with the
status of the MSN users:
Let's say that the jabber user sends a presence message with show=away and
status=foo. The MSN user is then away and I can see the status message. When
the jabber user sends an empty presence message (neither show nor status) the
MSN user becomes available but it its status message remains 'foo' while the
user status message is empty in the jabber network.
Has anyone noticed this?, is this really a bug?
Anyway I'd like to know if there is some way of changing this.
Best regards,
Jorge
From [EMAIL PROTECTED] Mon Jan 23 16:13:40 2006
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Mon Jan 23 16:20:20 2006
Subject: [py-transports] PyMSNt file transfer UP!
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Stian Barmen wrote:
> Gajim looks for a resource for sending files and therefor disables the
> send file option. The JEP does not require this but an example is
> presented. Could this feature be included? This way a client would be
> able to check for FT support in the transport.
jep-0095 seems to indicate that the client should be disco'ing the
resources to find out if they're supporting si and file-transfer.
I know that someone is working on making gajim FT with resources not
on the roster work (it doesn't atm, apparently). Just because there's
no non-blank resource online doesn't mean that iq/disco/si/ft won't
work.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED] Mon Jan 23 18:37:25 2006
From: [EMAIL PROTECTED] (Stian B. Barmen)
Date: Mon Jan 23 18:37:20 2006
Subject: [py-transports] PyMSNt file transfer UP!
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Norman Rasmussen skrev:
> Stian Barmen wrote:
>
>> Gajim looks for a resource for sending files and therefor disables the
>> send file option. The JEP does not require this but an example is
>> presented. Could this feature be included? This way a client would be
>> able to check for FT support in the transport.
>>
>
> jep-0095 seems to indicate that the client should be disco'ing the
> resources to find out if they're supporting si and file-transfer.
>
> I know that someone is working on making gajim FT with resources not
> on the roster work (it doesn't atm, apparently). Just because there's
> no non-blank resource online doesn't mean that iq/disco/si/ft won't
> work.
>
Yes I understand this also, but for the current version this must be
supported for FT to work both ways. If it is not a big thing to
implement this would be a welcome feature for the many Gajim users.
-stian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://modevia.com/pipermail/py-transports/attachments/20060123/2ad759ed/attachment.html
From [EMAIL PROTECTED] Mon Jan 23 19:25:45 2006
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Mon Jan 23 19:25:51 2006
Subject: [py-transports] PyMSNt file transfer UP!
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On 1/23/06, Stian B. Barmen <[EMAIL PROTECTED]> wrote:
> Yes I understand this also, but for the current version this must be
> supported for FT to work both ways. If it is not a big thing to implement
> this would be a welcome feature for the many Gajim users.
I've previously investigated fixing the resources in the yahoo
transport, and it eventually is just a mess. It's much easier to
leave it the way it is. That being said, I'm not sure how 'valid'
having an online contact with no resource is. I think it half works
because the transport is seen to be a server in itself, so it can get
away with bluring the client/server line far more than an xmpp server
can.
all-in-all, a quick fix in gajim is the easiest way to fix this.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED] Mon Jan 23 19:59:14 2006
From: [EMAIL PROTECTED] (Stian B. Barmen)
Date: Mon Jan 23 19:59:27 2006
Subject: [py-transports] PyMSNt file transfer UP!
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Norman Rasmussen skrev:
> On 1/23/06, Stian B. Barmen <[EMAIL PROTECTED]> wrote:
>
>> Yes I understand this also, but for the current version this must be
>> supported for FT to work both ways. If it is not a big thing to implement
>> this would be a welcome feature for the many Gajim users.
>>
>
> I've previously investigated fixing the resources in the yahoo
> transport, and it eventually is just a mess. It's much easier to
> leave it the way it is. That being said, I'm not sure how 'valid'
> having an online contact with no resource is. I think it half works
> because the transport is seen to be a server in itself, so it can get
> away with bluring the client/server line far more than an xmpp server
> can.
>
> all-in-all, a quick fix in gajim is the easiest way to fix this.
>
>
>
Ok, i did a ticket for gajim svn. :)
http://trac.gajim.org/ticket/1449
Thanks for the thorough answer!
-stian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://modevia.com/pipermail/py-transports/attachments/20060123/80b04ed3/attachment.htm
From [EMAIL PROTECTED] Tue Jan 24 06:40:45 2006
From: [EMAIL PROTECTED] (Alexey Nezhdanov)
Date: Tue Jan 24 06:41:04 2006
Subject: [py-transports] delays in pyAIM-t and pyICQ-t
Message-ID: <[EMAIL PROTECTED]>
Hello.
I have noticed that recently these two transports began to deliver messages
very slowly. Actually ICQ delay someimes reaches 60 seconds, and usually
about 30-40 seconds. AIM delays is one degree less and variates in interval
5-20 seconds.
Is anybody seeing the same behaviour with these transports?
--
Respectfully
Alexey Nezhdanov
