XEP-0060 clearly defines last item configuration for every nodes
Last item can be send:
- never
- when a new subscription is processed
- when a new subscription is processed and whenever a subscriber comes online
this is the way pubsub should behave, and that's fine.
but, here is what we can read at "12.1 Notification Triggers"
"The entity is not subscribed but is eligible to do so and has sent
presence containing appropriate entity capabilities data to a service
that supports filtered notifications (effectively establishing a
"temporary subscription" based on an expressed notification interest);
when the service first receives such presence, it sends the last
published item to the entity (sending it only once upon first receiving
such presence, not on subsequent presence updates that contain the same
notification interest)."
i think associating entity capability to a temporary subscription is not
a good point. changing caps should not modify your subscriptions but
change the way pubsub filters notifications. in my opinion caps and
pubsub are really two distinct layers of the server. why ?
cause pubsub is server centric, while caps is client connection related.
simple example:
let define user 1 from server A and user 2 from server B.
let define pubsub service P on server A only.
let define caps service C
1 and 2 are subscribed to each other, both with tune capability switched off.
now, 1 publish some tunes, then B send a presence with tune capability
switched on. let's describe what differenciate the two approaches:
1) pubsub and caps are distinct: pubsub is a service, caps is a filter.
1 uses P and C on A, 2 uses P on A and C on B.
in that situation, P just does pubsub job regardless of entities
location and all works fine. 2 is logged on B and only B have a
consistent information about 2's effective presence and capabilities.
P sends tunes to B, which filters or not the event depending on 2's caps
and presence.
in that case, changing capabilities can not results as receiving last
item without explicitely asking for.
but in that case, pubsub/pep behaviour remains consistent, and pubsub
service do not have to maintain caps/presence data for all external
subscribed entities.
2) pubsub and caps are service working dependently, changing caps also
changes subscriptions.
1 uses P and C on A, 2 uses P and C on A as well.
in that case, A stores caps from 1 and 2, so changing caps allows to
change subscriptions using pubsub internals as stated in 12.1 chapter
from XEP-0060, so changing capabilities results as receiving the last
items.
while that may seems logical, i really think this design is really bad
cause in that case, pubsub/pep bahaviour can not be consistent and
efficient for two reasons:
- pubsub service must cache caps of all subscribed users including
users from external domains. this does not scale. while this could be
working for a small home server, it will definitively not scale for
very big servers with lots of federated users through s2s.
- as caps is part of pubsub service and not a simple connection filter,
caps is running pubsub side. as a result it can not be consistent.
if client dropped connection on remote server, you have no way pubsub
side to get that information and continue to send events that may go
to offline spool if not explicitely defined as headline.
if s2s link is temporary down while remote client changes its
capabilities, your pubsub service has unconsistent subscriptions and
start sending events to users that should not receive ones.
