On Sunday 05 March 2006 12:48, Norman Rasmussen wrote:
> JEP-0018 isn't even Historical, it's Rejected - "Implementation of the
> protocol described herein is not recommended under any circumstances."
>
> Rather privacy lists, as defined in RFC 3921, and examples of use in
> 'JEP-0126: Invisibility' (http://www.jabber.org/jeps/jep-0126.html)
> should be used.
>
> If any privacy/invisible changes are made, they need to be with
> regards to the latter, _not_ the former.
>
Sorry. I was basing my use-case on Psi's current behaviour. Allow me to
abstract.
Regardless of implementation, my idea is this: The proprietary transport would
use the status that its pseudo-contacts (eg.
[EMAIL PROTECTED]) see, in order to determine which status
it advertises to MSN users(eg. [EMAIL PROTECTED]). It would then advertise
this same status to the jabber user who is subscribed to the transport (eg.
[EMAIL PROTECTED]).
The status seen by the transport (eg. msn.montague.net) would only be used to
determine whether to connect (or remain connected) to the proprietary
network.
Would this work for getting around the problem of invisibility, or am I still
missing something?
David
From [EMAIL PROTECTED] Sun Mar 5 13:52:50 2006
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Sun Mar 5 13:52:55 2006
Subject: [py-transports] Idea for handling invisible
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On 3/5/06, David Laban <[EMAIL PROTECTED]> wrote:
> Sorry. I was basing my use-case on Psi's current behaviour. Allow me to
> abstract.
no problem, there was a discussion around privacy lists, but I think
it didn't really go anywhere. I think everyone agrees that making an
Aunt-Tilly front end for privacy lists will be quite challenging.
> Regardless of implementation, my idea is this: The proprietary transport would
> use the status that its pseudo-contacts (eg.
> [EMAIL PROTECTED]) see, in order to determine which status
> it advertises to MSN users(eg. [EMAIL PROTECTED]). It would then advertise
> this same status to the jabber user who is subscribed to the transport (eg.
> [EMAIL PROTECTED]).
agreed, previously I think this is done via subscriptions, but tying
in presence makes sense. Makes more work for James of course :-)
> The status seen by the transport (eg. msn.montague.net) would only be used to
> determine whether to connect (or remain connected) to the proprietary
> network.
*tick*
> Would this work for getting around the problem of invisibility, or am I still
> missing something?
with the horrid way presence invisibility is being used, I think this
would still work both ways.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED] Sun Mar 5 23:44:30 2006
From: [EMAIL PROTECTED] (Albert Holm)
Date: Sun Mar 5 23:45:02 2006
Subject: [py-transports] Working twisted version dependencies for pyicq-t
Message-ID: <[EMAIL PROTECTED]>
Hi
Which versions of twisted are known to work with pyicq-t? pymsn-t seems to
work with both twisted-1.3 and twisted-2.0 but, honestly, pyicq-t-0.7 does
not seem to be working at all, atleast not with twisted-1.3.
/Albert
From [EMAIL PROTECTED] Mon Mar 6 00:01:26 2006
From: [EMAIL PROTECTED] (Daniel Henninger)
Date: Mon Mar 6 00:01:32 2006
Subject: [py-transports] Working twisted version dependencies for pyicq-t
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
When you say "does not seem to be working at all" .. can you be more
specific? =D What errors are you seeing? Have you run it in debug
mode to see what it's doing?
Daniel
On Mar 5, 2006, at 6:44 PM, Albert Holm wrote:
> Hi
>
> Which versions of twisted are known to work with pyicq-t? pymsn-t
> seems to
> work with both twisted-1.3 and twisted-2.0 but, honestly, pyicq-
> t-0.7 does
> not seem to be working at all, atleast not with twisted-1.3.
>
> /Albert
> _______________________________________________
> py-transports mailing list
> py-transports@blathersource.org
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
>
