On 20-Nov-2009, at 04:20, Dave Cridland wrote:
> I'm less than convinced that's a reasonable assertion with pubsub nodes -
> change is, I'd expect, typically more commonplace. Deletions are very common
> - historical items are removed, etc.
Agreed, but I'm not sure why this is a problem.
> With just simple PEP, there's hundreds of nodes I subscribe to, and sending a
> ver string to each of them to resynchronize - in the name of efficiency, no
> less - seems like a bad idea.
If you're making the request in the first place the worst case is that
you add a few bytes for no payoff. The best case is that you add a few bytes
and save a huge amount of bandwidth since you're already caught up on state. My
point is that you're going to be making the request /anyway/. You might as well
pay the marginal cost of the version attribute in order to enjoy potentially
huge savings in bandwidth.
> In particular, I don't see the fundamental advantage of not simply requesting
> (or receiving automatically, for PEP) all items in the node at the beginning
> of each session. In certain pathological cases, this may be considerably more
> bandwidth, but in no case will it save round-trips.
No one says you have to request items when subscribing to a node. Nodes
can be configured to auto-send them anyway. Version costs you nothing in these
cases and everyone can do it whatever way they wish based on their application
and circumstances.
> On the other hand, I don't think this mechanism is suitable for PEP, and
> other pubsub services where there is a presence relationship. In these cases,
> it seems logical to consider some alternatives, probably based on presence.
I think the cost is marginal, even for PEP. If your application is
going to make the get-items request, adding a version is marginal cost. If your
application doesn't need to get-items, then you don't even need to be
discussing versions.
-bjc
