[ghns] ghns status, api, etc.

Josef Spillner spillner at kde.org
Mon Jun 22 23:28:34 PDT 2009


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

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

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.

> P.S. Josef, are you on the list? or do we need to keep cc'ing you? ;)

Surely I'm subscribed to the list. If you CC me, I think Mailman is smart 
enough to filter me out of the recipient list of the message so either way I 
get exactly one copy. Hurray for smart software.

Josef



More information about the ghns mailing list