[ghns] ghns status, api, etc.

[Jeremy Whiting]

On Tuesday 23 June 2009 00:28:34 Josef Spillner wrote:
> Am Dienstag, 23. Juni 2009 08:06:17 schrieb Jeremy Whiting:
> > From my end (knewstuff2 client) I'd like to expose as much functionality
> > that exists on the web interface as possible (and reasonable of course).
> > In order to do that I'm going to need something I think I'm already
> > getting from frank's api which is a unique identifier for each entry.  Is
> > that right Frank? Josef, if you could provide this that would be
> > excellent, take a look at Frank's xml feeds to see how he's added it (and
> > we should add it to the ghns spec probably also).
>
> There's knewstuff/doc/Identification.txt which presents the i18n-id
> comparison algorithm. It's a bit more complex than just a global ID but its
> advantage is that it will detect duplicates across servers. So it all
> depends on what you want to achieve: Should entries be unique on one server
> or among all potential GHNS servers? In the former case, we could just push
> out the internal database id, in the latter case nothing else but i18n-id
> can ever work. (Except maybe checksums on a subset of the entry tags so
> that an entry's evolving nature including translations and comments are
> taken into account.)

That works fine for internal identification of an entry, but does not work for 
client to talk to the server about an entry unless we all three use the same 
hash function.

> > Second I'd like to be able to ask each web api if entry x is updateable.
> > There have been numerous wishlist requests to see what's been installed
> > in the past via knewstuff2 and I'd like to provide this.  I have all the
> > data in the registry I keep of what's been installed, including each
> > entry's xml, so I should be able to create a feed in memory of installed
> > items, then ask the server each came from to see if it is updateable. 
> > One advantage of this could be a button to update all like most package
> > managers have.
>
> I thought this is what KNS::Entry::Updateable is for? It is set
> automatically when an entry has a newer version in the feed than on disk.

Yes, and that works fine for feeds, but once an entry isn't in any of the feeds 
anymore, the client has no way to ask the server about it anymore.

> We could additionally have a method for querying just the possibility to
> update for any of the installed items, but this is going to cause a lot of
> traffic if you aim at one request per item. In this case, the HTTP headers
> will always be a lot larger than the request itself.

Yes, that's true, however I see no other way around taking a list of installed 
entries and finding out which ones are updateable when some may not be in any 
of the automatically fetched feeds.  If you have another idea how that could 
be done I'm more than willing to discuss, but I don't see another way at this 
point =)

thanks,
Jeremy