[ghns] ghns status, api, etc.

[Jeremy Whiting]

On Wednesday 01 July 2009 18:26:54 Josef Spillner wrote:
> 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.

Anyone know of such a feed validator? and if one exists, it wouldn't have 
worked with the feeds from ods sites for a long time now... I do agree we need 
a central place to store releases of the spec (fd.o =) I'd like to get the 
spec into xdg-specs on gitorious.org soon, so we can collaborate on it a bit 
easier.  We could also have apps/libraries that use the spec add themselves to 
the list of users of it there.

> - 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.

Yes, definitely.

> - 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.

Internal provider as in kanagram vs khangman providers both hosted on 
stuff.kde.org?  I'll look at the client code, but I think that should be ok if 
those are not 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?

Um, no. I was hoping we could add a method for the client to ask the server if 
entry x has updates where x is the id.  Will this still work (i.e. are newer 
versions of an entry tied to older ones somehow?)  If so I guess that's fine.

Jeremy