On Wed Dec 14 11:53:50 2011, Sergey Dobrov wrote:
I don't understand why to do that. It can store just the last one to
store it in it's offline storage. I don't see an overhead here,
servers
store offline messages for long time ago.
This is storing much more data.
> * The receiving server does not know what ACL should be being
applied
> to the node items, so is not able to correctly distribute the
items.
It doesn't need to know anything about ACLs. Sender will just send
to
bare JIDs, only for allowed JIDs.
It's not clear to me that ACLs are irrelevant here. But I'll concede
they could be.
Irrespective of this, other node configuration issues probably will
have a marked effect.
> * [Not an impossible failing but heavily undesirable] This
generates
> something of a bandwidth explosion.
I not agree. I think that it will decrease a bandwith, at least S2S
since we have not to send each event to each resource, we have not
to
send last item through S2S each time new resource connected.
It depends on whether the last item saving and per-resource saving
outweighs the number of irrelevant items sent.
This in turn depends on a number of things, including publish
frequency, number of resources, and so on. I would note that the
saving by number of resources is likely to be very small - most
contacts will only have one resource. So the real saving in bandwidth
will be whether the number of offline/online events outweighs the
number of updates sent when the contact is offline.
> If you want to be able to use pubsub without mutual presence
> subscriptions I suggest using one of the other subscription types
> instead of the presence-based +notify magic, which relies on
> presesence.
For example? Obviously, I can subscribe to nodes directly but where
to
store the list of subscribed nodes? I think that this problem must
be
definitely solved since it breaks a PEP idea at all.
You can query the PEP service and it'll tell you the subscribed
nodes, so you only need to store the services - in your described
scenario these services would be stored in your roster, which is
convenient.
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
