[ghns] ghns status, api, etc.

[Josef Spillner]

On Thursday 02 July 2009 01:08:41 Jeremy Whiting wrote:
> I'll check to see if I'm
> getting what I need from the ODS and DXS providers (a unique id for each
> entry)

I've added support for that in Hotstuff a few seconds ago which must manually 
be enabled because it's experimental. Which leads to a whole bunch of other 
questions we should get a consenting opinion on:

- Now that quite a few applications and libraries rely on the format(s) and 
protocol(s), how do we handle extensions and changes? There are several 
options. One could assume that things are only added and never removed. In 
this case, having version numbers and performing an equal-or-greater 
comparison would determine the compatibility. This sort of negotiation works 
great for connection-oriented protocols, but not so much for our rather ad-hoc 
request nature.
We could also determine stability cycles and have coarse-grained protocol 
switchovers.
In this particular case, the addition of an identifier might break strict 
schema-driven feed validators. We could always ignore unknown elements as a 
default policy as long as ignoring them doesn't introduce unwanted side 
effects.

- Similarly, we need to have an evolving specification text online along with a 
stable, widely accepted and implemented version, highlighting the changes 
which are about to be introduced.

- The semantic of what is a provider might not be clear. In my case, the 
identifier is taken from the database, which by convention always represents 
one provider. But it might contain entries of several categories. The 
identifier is unique for both, but not for categories across providers. 
Therefore, the namespacing mechanism would need to account for both hostname 
and internal provider identification to make an identifier globally unique.

- The design of Hotstuff is non-destructive, meaning that if entries are 
updated, the old information is still available. This means that the identifier 
would always change for each update. Is this the desired semantics?

Josef