Hi All,
I'm interested in installing pyMSNt on Mac OS X 10.4.1 Server. As
some of you might know, Apple has included jabberd with this version
of their server OS. I've been able to deduce the following version
info, and was wondering if anyone could help me out with what
prerequisites/versions, etc. are allowed.
Here's the version string returned when running python:
--
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
--
I checked /Library/Python/twisted/copyright.py to discover the
Twisted version, or so I think:
--
version="1.3.0rc1"
longversion="Twisted %s" % version
copyright="Copyright (c) 2000-2003 Matthew William Lefkowitz, all
rights reserved."
--
Lastly, `jabberd -v` returns:
--
Jabberd Version 1.4.3.1 Build 35
--
Can someone tell me what, if any, other prerequisites are required,
and how I might possibly check for them. Is there anything like CPAN
for Python?
Thanks very much in advance.
Kind regards,
Jay
From [EMAIL PROTECTED] Wed May 25 09:08:08 2005
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Wed May 25 09:08:15 2005
Subject: [py-transports] Storing messages on not available?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
huh, silly msn protocol
On 25/05/05, James Bunton <[EMAIL PROTECTED]> wrote:
> Tricky with MSN unfortunately.
> You're not allowed to do anything but receive presence packets when
> you're in the invisible state.
> That includes sending _and_ receiving messages :)
>
> That means the transport would have to bounce online and offline again.
> As a user option this isn't too bad. But I don't think it's reasonable
> default behaviour.
>
> ---
>
> James
>
>
> On 24/05/2005, at 11:48 PM, Norman Rasmussen wrote:
>
> > Oh course what should happen (I'm not talking easiest or possible
> > here) - is that by deault, (or the user should be able to configure
> > the transport to work in the way if it's not the preferred default)
> >
> > 1) The transport MAY remain connected with a status of 'Appear
> > Invisible', it SHOULD deliver messages to users who have messages
> > waiting for them when that user's status changes to online. The
> > transport MUST not depend on it's 'owner' being online to be able to
> > deliver the message.
> >
> > 2) If a message is sent from the legacy network to a transport that is
> > connected with a status of 'Appear Invisible', then the transport MUST
> > forward that message to the user bare JID. This means that the
> > message gets stored in the user's offline mssage storage, and will be
> > delivered when they come back online.
> >
> > something like that?
> >
> > On 24/05/05, James Bunton <[EMAIL PROTECTED]> wrote:
> >> Yes. I agree with you for those two cases.
> >>
> >> But there is another, which is the one that concerns me.
> >>
> >> Lets say I have a friend, Fred, who lives in the USA. I live in
> >> Australia. Just about opposite timezones.
> >>
> >> I go online, send a message to Fred, he's offline. At the end of the
> >> day, I disconnect, the message is still queued. It has no possibility
> >> of being delivered until I log in again.
> >> While I'm offline sleeping, Fred comes online, and disconnects just
> >> before I wake up.
> >> I reconnect again, the message is still queued, because Fred is
> >> offline.
> >>
> >> All this while, I've sent the message, expecting the normal Jabber
> >> semantics. That is, a message is either delivered as soon as the
> >> contact comes online, or immediately if they are online, or it's
> >> bounced with an error.
> >>
> >> The only possible solution to this is to bounce the message after a
> >> few
> >> days perhaps. But I think it's better for it to bounce immediately,
> >> because delivery cannot be guaranteed.
> >> It makes the transport seem unreliable. I don't know when this person
> >> will get my message unless I understand how the MSN protocol works.
> >>
> >> That's why I won't implement it. And if MSN plus has it, well I still
> >> think it's bad :P
> >>
> >> ---
> >>
> >> James
> >>
> >>
> >> On 22/05/2005, at 6:09 PM, Steve Ramage wrote:
> >>
> >>> James Bunton wrote:
> >>>
> >>>>
> >>>> I don't think it's a good idea to buffer messages in this case.
> >>>
> >>> Hmmmm PyMSNt is a great product, but I still like using MSN at
> >>> certain
> >>> times, and PyMSNt at others.
> >>> Before anyone goes off on me for it, I had a paragraph long
> >>> explanation but I considered it to aggressive
> >>> and would probably cloud my point, and maybe be considered a flame,
> >>> so
> >>> I won't justify it. One extension
> >>> I use for MSN that adds alot of functionality is Messenger Plus, it
> >>> has some really neat features like sending
> >>> offline messages. Everything is done client side, meaning that if you
> >>> turn your computer off, and the contact
> >>> comes and goes, they don't get it. Its the next time you see them
> >>> sign
> >>> on. I do not think that this is a bad
> >>> feature to have.
> >>>
> >>> I would think it awkward and wierd to send a message while you were
> >>> offline, as the
> >>> person couldn't really reply or anything to it. I think that PyMSNt
> >>> should implement this kind of feature,
> >>> where it is stored till the next time they come online.
> >>>
> >>> You might ask well what good is that, if I'm online and they come
> >>> online I can just message them. Well the fact is
> >>> that normally I have 2 computers on Jabber at all times, sometimes 3.
> >>> So the message would be sent
> >>> if and when they signed on. There are two situations that would be a
> >>> problem, in theory.
> >>>
> >>>
> >>> ----- Problem A -----
> >>> 1: I'm at home I send an offline message
> >>> 2: Message is sent
> >>> 2: Person replies
> >>> 3: I login at work, and I don't see it.
> >>>
> >>> ----- Problem B -----
> >>> 1: I'm at home and send an offline message
> >>> 2: I login at work
> >>> 3: Person logs in
> >>> 4: Offline message is sent, I have no way of knowing it is
> >>> 5: Person replies to laptop and I don't necessarily know what they
> >>> are
> >>> talking about.
> >>>
> >>> Problem B is easy, at step 4,the transport messages the user at the
> >>> same
> >>> resource that a new message to the user would be routed, either 'as
> >>> the user',
> >>> or the transport, but I think the user is better and states that the
> >>> following message
> >>> has been delivered.
> >>>
> >>> Problem A is not so easy, problem A is atleast aftering giving it two
> >>> minutes of thought
> >>> while thinking of Problem B unsolvable. The good thing about Problem
> >>> A
> >>> is that we can
> >>> ignore it because it has always been a problem and always will be. In
> >>> other words
> >>> Problem A isn't a new problem nor is it created by this kind of
> >>> offline message.
> >>>
> >>> The following happens now
> >>>
> >>> 1: Person Sends message to me.
> >>> 2: I login at work
> >>>
> >>> I have no idea that the person messaged me, and won't reply at all to
> >>> the person who messaged me,
> >>> we live in this world now, so I think that 'queued until you see the
> >>> contact online' is a good idea to be
> >>> implemented.
> >>>
> >>> Steve Ramage
> >>> JID: sjr A.T. sjrx.net
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > --
> > - Norman Rasmussen
> > - Email: [EMAIL PROTECTED]
> > - Home page: http://norman.rasmussen.org/
> > _______________________________________________
> > py-transports mailing list
> > [email protected]
> > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
> >
>
>
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.org/
From [EMAIL PROTECTED] Wed May 25 13:04:15 2005
From: [EMAIL PROTECTED] (James Bunton)
Date: Wed May 25 13:04:20 2005
Subject: [py-transports] Installing pyMSNt on Mac OS X 10.4 Server
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
What you've got should work just fine :)
Please let me know how you go installing it, so I can document what to
do for others (and perhaps make the process easier if necessary).
Good luck!
---
James
On 25/05/2005, at 11:08 AM, Jay wrote:
> Hi All,
>
> I'm interested in installing pyMSNt on Mac OS X 10.4.1 Server. As some
> of you might know, Apple has included jabberd with this version of
> their server OS. I've been able to deduce the following version info,
> and was wondering if anyone could help me out with what
> prerequisites/versions, etc. are allowed.
>
> Here's the version string returned when running python:
>
> --
> Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
> --
>
> I checked /Library/Python/twisted/copyright.py to discover the Twisted
> version, or so I think:
>
> --
> version="1.3.0rc1"
> longversion="Twisted %s" % version
> copyright="Copyright (c) 2000-2003 Matthew William Lefkowitz, all
> rights reserved."
> --
>
> Lastly, `jabberd -v` returns:
>
> --
> Jabberd Version 1.4.3.1 Build 35
> --
>
> Can someone tell me what, if any, other prerequisites are required,
> and how I might possibly check for them. Is there anything like CPAN
> for Python?
>
> Thanks very much in advance.
>
> Kind regards,
>
> Jay
> _______________________________________________
> py-transports mailing list
> [email protected]
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>