On 01/12/2012 12:54 AM, Stephen Pendleton wrote: > > >> -----Original Message----- >> From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On >> Behalf Of Sergey Dobrov >> Sent: Wednesday, January 11, 2012 11:48 AM >> To: standards@xmpp.org >> Subject: Re: [Standards] PEP and PubSub >> >> (Arrows show a direction in which presences and events sent) >> sen...@example.net/1 (from) --------> (to) recei...@example.com/1 >> |-------> (to) recei...@example.com/2 >> |-------> (to) receiv...@example.com/1 >> <-------> (both) >> this_receiver_will_work_any...@example.com/1 >> ... >> >> And I really don't agree that the situation is cover only my usecase. > > I'm pretty sure you will need to expand on this explanation. Is your diagram > showing your solution, the current situation of things, or the problem > itself? What is it describing, what is the problem statement?
The problem is that receiver (and all his resources) and receiver2 will not receive any events from sender. The solution is to filter messages on the receiver's server because it knows all about availability and features of it's clients. For now the filtration is undertaken on the sender's server. This means that sender's server MUST store all capabilities of each contact in each it's user roster to make decision which messages will be sent and which filtered. That may lead to consume a lot of memory. Also, this makes difficult (or impossible) to filter out events for clients which presences we don't know (e.g. with to subscription). So, the new schema is: <sender@server/resource> --(publish)--> <server> --(to=receiver@server)--> <rserver | filtering> ---> <receiver@server/resource> > > > > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
