From: [email protected]
To: [email protected]
Date: Tue, 7 Jul 2009 15:13:23 -0400
Subject: Re: [PubSub] Timestamp on items and versioning
On 7-Jul-2009, at 14:00, Robin Collier wrote:It seems like the initial request
I made to have timestamps on items
is being somewhat hijacked into a "what is the best way to implement
versioning" thread. The initial request had nothing to do with versioning
and I would hate to see the idea turned down because of the issues
with using it in this manner.
Can it be used for other problems, maybe. But that is beyond the point
of knowing when an item was published, which was the original request.
That being said, it could certainly be used to version actions against an
item (the service can ensure the timestamps are different) in a node,
but would probably not be appropriate for versioning changes to the node
itself.
I just don't feel that there's much special about time-of-publish that
warrants a special attribute in the <item/> element, and there's not much in
the way of other places to put it. I agree with the earlier comment that there
are many potential "special" attributes that would warrant the same treatment,
at which point the XML gets to be pretty crazy.
I have to assume this is a custom application (since no client out
there reads time stamps as-is) so what's the harm in just adding a <timestamp/>
element to the <item/> when you do the publish? The only downfall with that
approach which I see is that there is no possibility for some kind of generic
"network" layer service which can do fancy aggregations or that sort of thing.
If the sole purpose is to avoid fetching redundant data, then roster-style
versioning is a much better approach, IMHO.
Do you have some specific need for generic time stamps on all PubSub
items regardless of context?
I gave several reasons for its inclusion in the original request, so I will
just link to it here,
where the original thread started.
In addition to what was listed in the original thread, it can be used to
synchronize the
order of actions when doing a get items and an item from the same node is
deleted.
There is no way to currently know if the same item received in the get has
actually
been deleted or not.
-bjc
_________________________________________________________________
Internet explorer 8 lets you browse the web faster.
http://go.microsoft.com/?linkid=9655582
