yes I think we should recommend a an increasing integer. But should
allow any string. So if some server vendor prefers hash codes or GUIDs
for the versioning then this is fine for me too.
Exactly.
Sometimes flexibility comes back to bite you. I'd prefer to keep things
simple if we can. What does the extra flexibility really do for us, and
is it worth the cost?
Well I think it is better to be flexible in this case otherwise its
forcing server implementors to implement this in a particular way when
there is no real need to, what if in a particular implementation its
more efficient to implement it as GUIDs for example as Alex suggested
because of how its clustered or how the database is implemented, in my
case id want to implement this as a compressed timestamp rather than as
an increasing integer, and as far as the spec is currently written and
how it would work for clients it wouldn't make any difference what the
version identifier is as it isn't (and IMO MUST NOT) take any meaning
from the value of the version identifier so things stay nice and simple,
as as soon as clients start taking any meaning of what the version
identifier means you are introducing a whole raft of potential
interoperability issues and bugs that need not exist.
The only reason this scares me is that strictly increasing numeric
sequences have proved useful in the IMAP world, because clients can
spot when things go wrong much more easily.
I think this its a very very bad idea for the clients to take any
meaning from the version identifier as explained above, its just opening
a pandora's box of potential bugs and issues, far better for it to just
be a opaque string as far as the client in concerned, which also helps
to keep things as simple as possible.
Plus, nobody can get it wrong.
How exactly are they going to get it wrong if its an identifier that
only the server is interpreting the meaning of?
There's no way that even a 32-bit unsigned integer is going to
overflow - if you did an update every second, it'd take 136 years -
but if that still unnerves you (in case PSA turns into the undead, or
something), use a 64-bit unsigned integer.
Its possible even if unlikely, what if several updates were made in one
second because of some kind of bulk update for example, at the very
least the spec MUST define what should happen if the number is going to
overflow, i.e. reseting to 0, even though it is unlikely.
Richard
