Re: [jdev] Invisibility. Was: Presence of type "available"not allowed?

[Tomasz Sterna]

Dnia 2008-05-08, czw o godzinie 14:51 -0600, Peter Saint-Andre pisze:
> AFAIC, the fundamental problem here is that no one is excited enough
> about invisibility to stand up and say "yes I love and need this
> feature and I will implement Spec X in the next 3 days if we can agree
> that it's the right way to go".

It took me one evening to implement XEP-0126 in jabberd 2, though. ;-P


--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
.._.(_.)_ im:smoku (AT) xiaoka (DOT) com

[Peter Saint-Andre]

On 05/09/2008 3:58 AM, Tomasz Sterna wrote:
> Dnia 2008-05-08, czw o godzinie 14:51 -0600, Peter Saint-Andre pisze:
>> AFAIC, the fundamental problem here is that no one is excited enough
>> about invisibility to stand up and say "yes I love and need this
>> feature and I will implement Spec X in the next 3 days if we can agree
>> that it's the right way to go".
>
> It took me one evening to implement XEP-0126 in jabberd 2, though. ;-P

Perhaps because 126 pushes the complexity onto the client. :)

/psa

[Tomasz Sterna]

Dnia 2008-05-09, pią o godzinie 16:04 -0600, Peter Saint-Andre pisze:
> > It took me one evening to implement XEP-0126 in jabberd 2,
> though. ;-P
>
> Perhaps because 126 pushes the complexity onto the client. :)

My god. You're right.
All the time I had XEP-0191 in mind... and a completely different topic.
Well... to much work lately, I think.
Please discard the whole conversation and I will just silently stick my
head into my a... ;-)


But backing to the topic...
Did you have any time to look at my proposal of layered privacy lists?
This could serve as a base for an easier for clients XEP-0126
replacement.



--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
.._.(_.)_ im:smoku (AT) xiaoka (DOT) com

[Peter Saint-Andre]

On 05/09/2008 4:25 PM, Tomasz Sterna wrote:
> Dnia 2008-05-09, pią o godzinie 16:04 -0600, Peter Saint-Andre pisze:
>>> It took me one evening to implement XEP-0126 in jabberd 2,
>> though. ;-P
>>
>> Perhaps because 126 pushes the complexity onto the client. :)
>
> My god. You're right.
> All the time I had XEP-0191 in mind... and a completely different topic.
> Well... to much work lately, I think.

Oh don't worry, we all understand about too much work. :)

> But backing to the topic...
> Did you have any time to look at my proposal of layered privacy lists?
> This could serve as a base for an easier for clients XEP-0126
> replacement.

No time yet, but I think it's a worthy idea.

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Andreas Monitzer]

On May 10, 2008, at 00:25, Tomasz Sterna wrote:
> But backing to the topic...
> Did you have any time to look at my proposal of layered privacy lists?
> This could serve as a base for an easier for clients XEP-0126
> replacement.

Yes, right now for implementing XEP-0126, you have to do some AI magic
to get it to work, when you assume that the user might have set up a
privacy list that has to be honored even when the user is invisible
(which is a valid assumption). That was a no-go for me when I looked
at implementing it for Adium.

andy

[Peter Saint-Andre]

On 05/10/2008 3:40 AM, Andreas Monitzer wrote:
> On May 10, 2008, at 00:25, Tomasz Sterna wrote:
>> But backing to the topic...
>> Did you have any time to look at my proposal of layered privacy lists?
>> This could serve as a base for an easier for clients XEP-0126
>> replacement.
>
> Yes, right now for implementing XEP-0126, you have to do some AI magic
> to get it to work, when you assume that the user might have set up a
> privacy list that has to be honored even when the user is invisible
> (which is a valid assumption). That was a no-go for me when I looked at
> implementing it for Adium.

Right. That's why I think XEP-0186 is a very useful shortcut around the
madness of invisibility based on privacy lists (even if in some server
implementations the two might use the same backend).

Peter

--
Peter Saint-Andre
https://stpeter.im/