Hi,
can you tell me at what stage is the development of the file transfer in
the PyMSN-t? If you have not enough resources, I would like to
contribute. Yanis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://modevia.com/pipermail/py-transports/attachments/20051114/39eb0952/attachment.pgp
From [EMAIL PROTECTED] Mon Nov 14 22:25:05 2005
From: [EMAIL PROTECTED] (Lars T. Mikkelsen)
Date: Mon Nov 14 22:25:20 2005
Subject: [py-transports] PyMSNt: Messages from MSN users are bounced on
errors
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On Mon, Nov 14, 2005 at 02:26:05PM +0100, Lars T. Mikkelsen wrote:
> I think the original MSN Messenger client has a built-in feature telling
> the user when a message was not delivered. I remember seeing the message
> "The following message could not be delivered:" when for instance a
> contact has gone offline (I found a picture of this on Google [1]).
> However, I don't know if it's only the MSN server that can determine if
> a message was delivered or if this is also possible for a client (i.e.
> PyMSNt). If the latter is not possible, I guess your idea is a nice way
> to fix it.
I did some testing with the official client. If I send a message <my
message> to an offline contact, the sending client will fail to create a
switchboard session - i.e.:
CAL 13 <user's passport>
217 13
The error code 217 simply indicates that the contact is offline. The
client will then display "The following message could not be delivered
to all recipients:\n<my message>" - this is displayed without the client
actually sending <my message>.
In two other tests I dropped and rejected incoming messages in my
firewall. While these messages were not received by the receiving
client, the sending client was not notified about these missing
deliveries by the server.
So I guess prefixing the message with "The following message could not
be delivered to all recipients:\n" and bouncing it, is the way to go.
Best regards,
Lars
From [EMAIL PROTECTED] Tue Nov 15 00:00:26 2005
From: [EMAIL PROTECTED] (James Bunton)
Date: Tue Nov 15 00:00:46 2005
Subject: [py-transports] TwistedWords 0.3.0 support
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
This is getting interesting :P
I don't want to drop support for such a new Twisted release. Perhaps
this little bit of fun I was experimenting with will be useful for you
too.
Have a look at this file
http://websvn.delx.cjb.net/websvn/filedetails.php?
repname=pymsnt&path=%2Ftrunk%2Fsrc%2Ftlib%2Fxmlw.py
Basically it provides xmlw.Element, SuxElementStream, parseText and
parseFile
It hopefully will work with Twisted 1.3, Twisted 2.0 with any words.
It first checks for Twisted 2.x or greater, if not, it falls back on
our internal domish because of all those bugs :P
It then tries to import the new twisted.words.xish, if that fails, it
imports from twisted.xish
In all the other files we then import from tlib.xmlw.
Sound ok?
---
James
On 15/11/2005, at 8:09 AM, Daniel Henninger wrote:
> Ok, consider this fix a "hack" fix. A real fix is to import the
> "correct" Element. =/ Thing is, between 0.1.0 and 0.3.0 of words, a
> lot of the xish stuff seems to have made it's way in, instead of
> staying in Xish. So now we have two versions of domish sitting
> around, one that's compatible with 0.1.0. and one that's compatible
> with 0.3.0. Now... the below fix works fine, all things considered,
> because really, all that happens in the xmlstream code is that same
> thing ... if it's an Element, it's turned into a string with toXml().
> So we're not hurting anything by doing it earlier, and that would
> provide backwards compatibility for now. I believe I'm going to leave
> the hack in for now, but it's looking like we're either going to need
> to embrace the new layout and say byebye to 0.1.0 support, or deal
> with it in a variety of other ways.
>
> Kind of a moving target sometimes, isn't it? ;)
>
> Basically, the low down is that the xmlstream code checks that what's
> passed to send "isInstance" of domish.Element. Well, it's not if
> we're not talking about the same exact domish.py. So it was passing
> our Element on through, which is indeed not a "sized" element.
>
> Daniel
>
> On Nov 14, 2005, at 11:00 AM, Daniel Henninger wrote:
>
>> This is sort of for James's benefit, but I thought I would throw it
>> out to the list. The change that occured that caused PyAIM to fail
>> with 0.3.0 ended up being that the send function no longer accepts an
>> Element. It's expecting that you will hand it a string. I've been
>> toying with overriding send anyway because I need to do so for
>> Jabberd2's component protocol (well, I think I haven't worked that
>> functionality out yet). So PyTransport need a:
>> def send(self, obj):
>> if type(obj) == Element:
>> obj = obj.toXml()
>> component.Service.send(self,obj)
>>
>> That does the trick. I'll be submitting the changes momentarily.
>> I'm going to pose this change on the twisted jabber list and see what
>> is said.
>>
>> Daniel
>>
>> --
>> "The most addictive drug in the world is music."
>> - The Lost Boyz
>>
>>
>>
>> _______________________________________________
>> py-transports mailing list
>> [email protected]
>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>>
>>
>
> _______________________________________________
> py-transports mailing list
> [email protected]
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
