On Fri Dec 16 09:41:11 2011, Sergey Dobrov wrote:
On 12/16/2011 01:02 AM, Dave Cridland wrote:
> On Thu Dec 15 12:54:28 2011, Sergey Dobrov wrote:
>> I meant that if I have a contact in my roster with "from"
subscription
>> then I will receive it's events but I don't want to receive them
because
>> I did not request it's subscription. I have to filter them
additional on
>> client side? Strange way...
>>
>>
> If you have a subscription 'from', then you won't receive any PEP
or
> presence.
I am receiving them when from subscription. I will never say before
check.
Well, then either your implementation is broken, or else the node's
owner has changed the access-model from the default (possible, but
unusual).
The specification clearly states that the default access model for
PEP ndoes is 'presence', and the presence access model only allows a
subscription for contacts in the owner's roster of 'from' or 'both'
(correspondingly, the contact will have the node owner as 'to' or
'both').
So if you have the contact as 'from', in the typical case you should
not be getting PEP events.
>
> If you have a subscription 'to', then you don't have PEP events,
because
> those are presence based (and you're not sending presence). But
you can
> use these to handle the item retrieval and maintain manual
subscriptions.
>
And will increase traffic for clients which don't support
microblogging.
The PEP protocol is again loss. The things that it was designed for
are
work well only for very simple protocols like moods.
Right, and I agree this isn't a perfect solution, but I don't think
filtering at the destination server is a solution either, I went
through this already.
What about this - what if we had some mechanism for having your PEP
service subscribe to remote nodes, so that you in effect had a node
which aggregated remote nodes for you? Then the net result is one
that can be subscribed to using the normal filtering methods, and
you're more or less getting what you're asking for, but structured
such that it fits into the existing framework, and isn't forcing
constraints onto the entire system.
I'm aware that XEP-0253 exists, maybe there's something we could do
that's somewhat more transparent (ideally, I'm thinking the contact's
service needn't know anything about the chaining).
The client's view would - hopefully - end up being of a local PEP
node containing all their contact's microblogging posts.
> I would note there are plenty of implementations that filter
properly,
> so I wouldn't say it's an impossible thing to do. Some of these
run
> quite big deployments.
May I ask about examples of such software and deployments? I am
worrying
about high load too.
Operators of such services may be able to comment here.
Also, I wanted to ask about big solutions which uses PEP/Pubsub in
real
life applications to learn how them work.
In my view, PEP is used quite heavily on the network as a whole.
I certainly see a large number of subscriptions across my server. I
have 97 contacts online currently, and 85 subscriptions, so a high
proportion of those contacts are using PEP-enabled clients. (We
internally generate a subscription at the root if there are any PEP
+filters, and one per extant node, so it's hard to translate this
into any percentage figures).
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
