[ghns] ghns status, api, etc.

[Jeremy Whiting]

On Tuesday 23 June 2009 10:03:32 Jeremy Whiting wrote:
> 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 =)

I can think of one other way to do this.  The client could ask the server for 
a custom feed and give the server all the entry id's it would like in the feed 
in the http headers. then get one feed back containing all the entry 
information for the requested entries.  That would only require one http 
request that way.  What do you think of that?

Jeremy

>
> thanks,
> Jeremy
> _______________________________________________
> ghns mailing list
> ghns at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ghns