On 01/10/2012 10:03 PM, Stephen Pendleton wrote: > > >> -----Original Message----- >> From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On >> Behalf Of Sergey Dobrov >> Sent: Tuesday, January 10, 2012 3:06 AM >> To: standards@xmpp.org >> Subject: Re: [Standards] PEP and PubSub >> >> 1. No, I can't. >> 2. Even if we will extend XEP-16 that it will be able to block events >> based on them node then it will be still bad solution because it's not >> efficient and has superfluous entities in the process. > > OK, it sounds like the REAL problem is that you perceive PEP to be an > inefficient solution to your particular use case. That is what I was trying > to figure out. It is a common complaint that PEP is inefficient, yet no one > really has quantified how PEP is less efficient than the alternatives. PEP is > based around presence and is what it is, and many of us depend on it, so let > us not break it.
I always said that it's POSSIBLE to make this changes backwards compatible with some transition period. I did not hear real problems with mine solution except a gtalk support, but if we will wait for google we will never go forward. Anyway, what is your suggestion to me? I need the protocol which is looks like a PEP, swims like a PEP but needs more close integration with the existent solution, what I have to do? Copy all specifications, change a namespace and then work with it? Do you think that it's really efficient solution? XMPP now have already many protocols which do the same things but in different ways. Why to invent another one? > >> >>> >>> >>>> >>> >>> >>> >>> >> >> >> -- >> With best regards, >> Sergey Dobrov, >> XMPP Developer and JRuDevels.org founder. > > > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
