[ghns] ghns status, api, etc.

[Jeremy Whiting]

On Wednesday 24 June 2009 23:56:54 Josef Spillner wrote:
> Am Mittwoch, 24. Juni 2009 23:50:51 schrieb Frank Karlitschek:
> > > 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.
>
> Maybe we talk about two different comparison functions here. The i18n-id
> algorithm was designed to support the detection of identical entries across
> servers despite differences in the variable parts of the meta information.
> Its usefulness comes in when people upload to several servers, for example,
> which I think will happen for those who want maximum exposure of their
> work. It is certain that all participants will have to agree on a global
> comparison function, similar to how hashing works in practice. The addition
> of the namespace leads to unique identification, but not to cross-server
> duplication detection.
> If this is what is wanted, then using a unique id per server is indeed the
> better option, and the namespace can remain implicit, e.g. by grouping the
> cache files per server instead of repeating the server name for each entry.

Frank, would it be difficult for you to use the above mentioned hash for 
generating the id tag? Just wondering about which direction this should go.  
There are advantages to both methods for sure. I'm just trying to figure out 
the implications of each.

Josef, Frank,
In a plasma meeting I attended yesterday, some interesting things came up.  
They would like to be able to ask knewstuff2 occasionally if certain data is 
updatable. e.g. KNewStuff2::IsEntryUpdateable(Entry*) or something like that, 
and invoke the update either automatically or through some ui of their own I 
guess.  I think we need to nail down the id algorithm/hash whatever before 
that will be feasible. (And before the installed items tab in the existing ui 
will be feasible). So here is how I see each approach.

Global id (independent of server, etc., as per hotstuff's implementation:
pros: 
- different hosts can serve the same data
- registry is simpler on the client
cons:
- the algorithm is more complicated
- the client needs to know which provider to check for updates, the same data 
can come from many different hosts

server namespaced id
pros:
- each host can provide its own algorithm, as long as it uses the same id 
consistently for the same entry, all is well
- only one host per downloaded item, so only one host to check for updates
- simpler algorithm
cons:
- different hosts serving the same data will not appear to be the same

can you think of any other pros cons to each method?

thanks,
Jeremy

> Admittedly my approach is more difficult to implement and more academic in
> nature :-)
>
> Josef
>
> _______________________________________________
> ghns mailing list
> ghns at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ghns