On Thu, Nov 19, 2009 at 3:01 PM, Dirk Meyer <[email protected]> wrote:
> Hi,
>
> catching up with the discussion now that I have more free time again.
> The ver attribute looks like what I need for XEP-0189 and stoarge in
> general.
> ...
>
For the persistent storage using pubusb I would like to send my presence
> status to the server with the auto-subscription hash and receive the ver
> attributes of all my storage nodes (pubkeys, bookmarks) and fetch the
> changed items.
>
> Dirk
>
> --
> ACK and you shall receive.
>
Here some original thoughts around History Id ('Ver') I had in mind earlier,
For the problem above, see smart recovery part, all that can be done really
clean way, not sure how those will be able to adapt to XMPP std in future.
- Ville
Item History Id
---------------
(currently timestamp used partially for the same purpose, but history Id
should quarantee consistency and must be able to be set by item publisher)
<item id='
ae890ac52d0df67ed7cfdf51b644e901'/>
=>
<item id='ae890ac52d0df67ed7cfdf51b644e901' act='i'
history='1234567890123456'/>
At least in pubsub, the node/collection level uniq history id for each item,
increased by each action (Insert/Update/Remove to item) on the node would
once again help to generate much more generic pubsub algorithms from
subscriber point of view as for many client side algorithms.
One should also quarantee if the 'History Id' is not set by item publisher
(which may be reasonable requirement btw) then the XMPP server should
quarantee the very same 'History Id' flow to be generated with the same set
up and same publishing flow. (Consistnency from two similar datasources can
then be quaranteed)
There was some discussion about this already, started by T. Koski I suppose
(I wasn't subscriber at that time). But I'll try to give my salt over the
earlier motivations.
This would allow header level handling at client side to keep data up to
date in generic model, even not knowing anything about the content itself
and leaving the actual data handling up to the contexts handlers only.
This would also allow the very same feed published on two sources to be
subscribed by one client and handling feeds as combiner, the latter message
from seconadry feed will be omitted. (More reliablity in case of failure,
which was important in Financial sector software) And still resolve the
conflict of updtaes received from two sources in a sequence, without
reliable HistoryId/Stamp the older update may overwrite the newer data.
Smart recovery from failures. : This can be either implement by sending
messages between client and server changing the information what are all the
changes at server side after highest History Id (requires server to keep
removals and updates up to date at least some time, buffer side and/or time
to remove from removals buffer can be configuratable).
This would be something like
<iq type='get'
from='[email protected]/barracks'
to='pubsub.shakespeare.lit'
id='items3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='princely_musings'>
<item history_form='1234567890'/>
</items>
</pubsub>
</iq>
Then it's up to set up and requirements if the client would require the full
action flow (All IUR events) or just the results for each items (like last
insertion/update/removal of the items after that history stamp)
For server side implementation of this allows smart recovery in a way, that
client sends his view to specif channel (Channel Id, Set<ItemId,HistoryId>)
against what the server may generate the response feed serving subscriber
always with orrect IUR messages in correct order.
Would the update hitory be important, that must be stored on other node to
collect details as some update actions (not content of those) might be lost
in this format. This functionlity would be allowed case by case by allowing
component to react subscribtion messages and to response through the system
the initialisation dataset back to the subscriber.
<iq type='get'
from='[email protected]/barracks'
to='pubsub.shakespeare.lit'
id='items3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='princely_musings'>
<item id='368866411b877c30064a5f62b917cffe' history='12'/>
<item id='4e30f35051b7b8b42abe083742187228' history='13'/>
</items>
</pubsub>
</iq>
With help of these two additional fields above ItemId the generic IUR
algorithms for pubsub can be written to nice little mathematical format and
implemented in very generic way from bith, publisher and subscriber point of
view.
One of the possibilities is then to describe proxy-XMPP pubsub service,
which then need to act only based on Channels, Nodes and ItemId,HistoryId
data, not ever been intrested in anylevel about the actual data delivered.
For content based pubsub I'd like to discuss couple of methodics, the latter
one most likely is somethig similar as implemented and planned already. As
well when putting the publish-subscribe nodes to the chains allowing the
code between them sounds more than intresting and familar. I have to take
time to investigate those ideas closer.
At the moment, couple of ideas to implement content based pub/sub easilly
(propably) and in generic model over the existing standard, leaving the
logic to publisher or published item modifier component attached to the
node(s).
