[ghns] ghns status, api, etc.

Jeremy Whiting jeremy at scitools.com
Wed Jun 24 15:07:11 PDT 2009


On Wednesday 24 June 2009 15:50:51 Frank Karlitschek wrote:
> On 23.06.2009, at 18:03, 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.
>
> Yes. Can´t we simply use the service provider as a "namespace"? I mean
> your unique ID would be the name of the service provider + the id you
> get from the server.
>
>
> For example the unique id of the content 1234 from openDesktop.org
> would be "openDesktop.org1234"

That's exactly what I was thinking, Josef, is this acceptable for HotStuff?

Jeremy

> >>> 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
> > _______________________________________________
> > ghns mailing list
> > ghns at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/ghns
>
> --
> Frank Karlitschek
> karlitschek at kde.org


More information about the ghns mailing list