[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tonight's match-up: gnome-keyring vs. kwallet! (was: Re: gnome-keyring branch is finished)

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: Tue, 20 May 2008 08:39:12 -0500

Is there any programmatic way of determining whether the user happens
to be running KDE or GNOME at run-time? That would result in behavior
that least-surprises users.

On Tue, May 20, 2008 at 4:41 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, May 19, 2008 at 02:05:25PM -0400, Mark Phippard wrote:
>> What happens at runtime if both KWallet and GNOME are present and
>> loadable? I'd personally like to see GNOME be given preference as it
>> worked nicer in my testing. I think it currently loads KWallet first,
>> so I assume that means it gets first chance.
>
> Let's just use a good-quality PRNG and let it decide what the default
> should be. For numbers between 0.0 and 0.5 inclusive, gnome-keyring wins,
> for numbers between 0.5 exclusive and 1.0 inclusive, kwallet wins.
>
> Alternatively, two dice, one for kwallet, one for Gnome-Keyring,
> might also do the job. This could possibly require repeated rolling
> -- whichever gets a higher number first, wins. We should probably
> appoint a neutral party for supervising the process.
>
> Matters will be complicated further should we ever grow GPGME
> support in the future. But we can delay that decision until
> further notice. Let's not tax our brains too much unless absolutely
> necessary.
>
> Oh, and we could also have committers vote, of course. But with
> paper ballots, please. Many people (including myself) don't trust
> other ways of voting too much.
>
> :)
>
> Stefan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-20 15:39:35 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.