On 12/20/2011 06:04 PM, Dave Cridland wrote: > On Tue Dec 20 09:06:07 2011, Sergey Dobrov wrote: >> We have the same disadvantages here: >> >> > I'm not convinced, but even if this is the case, it limits the scope. > > >> 1. node ACLs can't be used (but it can for filtering on destination >> server) > > I think they can, can't they? > > >> 2. all node items should be stored on this aggregation service (but it >> should not for filtering on destination server) >> >> > No, all items for the remote node only. So we're not forcing every > server to maintain a copy of your mood just to satisfy your > microblogging needs, which I think you would need if you enforced > local-only filtering. > > To put it another way, there's no speculative item storage; it'd all be > done by request.
The same request can be done for the filtering on destination method. > >> The only advantage here is that we can do that transparently and we will >> not break compatibility. Any other problems will be here in more complex >> shape. > > Those are big advantages, in my book. Look, the main problem is to update clients because clients are more widespread. Destination filtering will not break compatibility with clients. But chains can broke it depends on implementation. But even for server software we can maintain backwards-compatibility by using server caps. The transition period can be used during it filtering on sender can be announced as deprecated. > > For a start, no existing users can use either case - they need to do > things using manual subscriptions. It occurs to me that a very simple > change - making manual subscriptions to PEP nodes cause the > notifications to be sent out using type='normal' rather than > type='headline' - would cause the manual subscriptions to send data into > offline storage, which is already quite an advantage. > > But in general terms, PEP is done and deployed; changing it at all is > hard, changing it as radically as you propose is essentially a > non-starter. It seems to me that the PEP subset is simply not sufficient > for your needs; you need to use something more, whether that's more > XEP-0060 features, or some other, new, protocol. But trying to change > PEP because it doesn't fit your use-case is just not going to work. Ok, you are suggest me to invent my own protocol. But it will be reinvented PEP without the problems that we've found in the existent standard. So we just will have two protocols which make the same thing. Who will win in such case? I don't see where PEP is used in real life applications except of not important data such as moods which nobody will disturbed if them will not be delivered. I know that pubsub is used in some proprietary decisions (I developed the one and I saw an adult site based on pubsub recently), pubsub and not PEP! But you must keep in mind that it's much more easier to develop proprietary solution because it will be used only with your own code. If I will to write my own proprietary microblogging I will just patch the server and will not care but I want to make an open platform which anyone can integrate to. That's the main disadvantage of the my competitor. If not that one then what it will be? Proprietary has some advantages in the speed of write code since they don't want to coordinate it with anyone. But I can't solve such simple problem for more than half year. In such case XMPP will not look good for developers. Who will use PEP if it has such problems? We have XEP-277 and it is unsuitable for real life usage. Why that happens? Because people who start to work with PEP are hope that PEP is high quality standard which will be suitable for them application, maybe relying on reputation of XSF and older specifications them worked with. But if we will close the eyes on PEP's problems then who will use it? P.S. It will be really interesting if there are some examples of PEP usage in commercial usage. > > Dave. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
