On 2013-02-26 14:25, Paul Witty wrote:
[..]
>
The use case I have for this is where I want to use a PEP node (in
XEP-0223 style) as a way for multiple online resources to coordinate
working together. A resource publishes to the PEP node to say what it's
doing, and so when it goes offline unexpectedly I need some way for its
item on the PEP node to be removed. Though I can work around this by
checking the presence of the publisher for each published item, the
purge_offline feature (at least as I interpreted it) seems like an ideal
solution.
The other reason for doing partial purges on individual publishing
resources going offline, rather than waiting for all resources to go
offline is for increased predictability. If a user has e.g. a mobile
client, which is going on and offline as the signal comes and goes, the
purging of items will appear to be fairly random to the user publishing
from another client. If the purge is tied only to the publishing
resource, the user can be certain that when that resource goes offline,
the items it published will be purged.
Let me start by saying that of course you could use the protocol like
this if you wanted. Unfortunately, you are not really describing the use
case, but your idea of a solution for it. This makes it hard for me to
assess whether or not this is a good approach.
With all the issues you describe it does sound complex and reasonably
far removed from the Observer pattern we started out from. It might very
well be that the publish-subscribe protocol is not the best approach for
your problem.
I am curious about what you are working on, so if you could zoom out a
little that'd be helpful.
--
ralphm
