[ghns] ghns status, api, etc.
jeremy at scitools.com
Thu Jul 2 10:31:13 PDT 2009
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
> 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
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.
> - 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
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.
More information about the ghns