[Standards-JIG] JEP-0060: Comments on latest draft.

Bob Wyman bob at wyman.us
Mon Jun 28 20:47:05 UTC 2004


Boyd Fletcher wrote:
> I could see the append, but overwrite=false just drops 
> the message and sends an error.
	But, how does it know when something is in error?
	Append and overwrite=false both require that the server remember all
itemIDs that have been seen in the past. I can't prevent overwriting unless
I know if an itemID has already been used. Clearly, for append, I must have
a detailed list of all itemIDs ever used in order to enforce the policy.
But, I need the same list to do "overwrite=false" unless we write in new
constraints such as "Every itemID must be 'greater than' any previously used
itemID." If that rule was followed, I would only have to remember the last
itemID seen and then would reject any itemID what wasn't greater than the
last one seen. However, it isn't that simple... We would have to specify how
to handle "roll-over" (i.e. what is 2^32 + 1 ?) , we would have to specify
"collating sequence" for itemIDs (and potentially restrict them to integers
only), and we would have to specify how a publisher determines the current
itemID "high-water-mark" if it restarts after a crash. Etc.... This could
get messy.
	Enforcing constraints on itemIDs is a very difficult thing to do. It
should not be required of all servers.

> But their still needs to be a way to know **exactly** how the
> server will behave at all times. Anything else, results in 
> interoperable/incompatible systems.
	Yes, of course. We should be focusing on the problem of discovering
the server's configuration of its nodes rather than trying to restrict the
behavior.

		bob wyman





More information about the Standards mailing list