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?
-bjc
