On 26/02/13 14:34, Ralph Meijer wrote:
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.
I'm limited in how much specifics I can go in to (operating in a start
up, keeping what we're doing secret for a few months more), but I'll try
and explain as best I can.
A user has multiple resources logged on. Resource may participate in a
"session", and when they do so, they publish the information so that
each resource becomes aware of all the others are doing. When the
resource stops participating, it needs to inform all the other resources
that it has stopped doing so. In a case of a resource going offline
unexpectedly, it will not have the chance to send a message saying that
it has stopped participating, so there needs to be some way of
invalidating the information about its participation.
A couple of other constraints: resources logging on later need to be
able to retrieve information on what previously logged-on resources are
doing, and the information on how they are participating needs to be
kept private (only available to that user).
--
Paul
