Tomasz Sterna wrote: > Dnia 10-09-2007, Pn o godzinie 14:58 -0600, Peter Saint-Andre > napisał(a): >>> XEP-0186 is just this sh$%^ XEP-0018 in a pretty IQ envelope. >>> I hate it just as much as presence-invisible. >> Can you elaborate your reasoning? "I hate it" is not very helpful. :) > > Please do look at both the XEP-0016 and XEP-0186 specs. > It is spaghetti. So many conditions, corner cases, if this than thats.
Agreed. > Implementing it is even more horrible spaghetti. The whole presence > handling pipline needs to be intersected with all these special cases > handling conditions and tracking. Sorry about that. We pushed that protocol into RFC 3921 before it was fully baked, I think. > And I do not see a reason for this invisibility thingy existence too. I agree. But that's just me. Some people love it. > We do not have to mirror patches for deficiencies in legacy protocols. > We really could do better with Privacy Lists. I'm sure we could. The question is: do we throw away privacy lists or develop something better? I don't know if it is worth the time. Or at least I'm too lazy to work on a whole new protocol. >>> Maybe it's time to think of Stacked Privacy Lists (more than one PL >>> enabled at a time) that would make XEP-0126 much more sensible. >> Yes, we've talked about that for a long time. It's a fairly major >> change, but it may be worth considering. > > I do not think it is that major change. > Just a thin layer on top of XEP-0016 with one more advertised feature > and ability to activate another list without deactivating current. > > Let's consider this (by XEP-0016 2.4. Ex.11): > > <iq from='[EMAIL PROTECTED]/orchard' type='set' id='active1'> > <query xmlns='jabber:iq:privacy' xmlns:spl='urn:xmpp:stacked-privacy-lists'> > <active name='invisible-to-all' spl:insert='first'/> > </query> > </iq> > > that would activate list 'invisible-to-all' and insert it on top of > stack. If a packet passes the first active list it is put through second > and so on. Yes, something like that might do the trick. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
