Re: Request for comment (GNOME Keyring team): release date for GNOME 3.0
- From: Stef Walter <stef-list memberwebs com>
- To: gnome-keyring-list gnome org, release-team gnome org, authentication lists freedesktop org
- Subject: Re: Request for comment (GNOME Keyring team): release date for GNOME 3.0
- Date: Tue, 03 Nov 2009 18:57:48 -0600
Vincent Untz wrote:
> The release team is gathering comments from various teams to get a
> proper idea of which of March or September 2010 is more appropriate for
> the release of GNOME 3.0. The decision for the release date is following
> what we set in the 3.0 planning document [1]: we want 3.0 to be out in
> 2010, but we also want to make sure that 3.0 is rock-solid; your input
> will help us take an informed decision.
Thanks, I appreciate that.
> It'd be great if someone could summarize the status of the work that is
> being done in your team (especially for the shared keyring work that is
> being done with KDE), and how March or September would work for you.
Summary: It would be far far better to have a September GNOME 3.0
release. It's highly unlikely everything will be in place and stable for
2.30.
The 'Secret Service' (shared keyring API) work is going well, but is
nowhere near complete. It's very likely that much of it will be
implemented and in use by gnome-keyring 2.30. But I'd be naive to think
that it'd be stable and all the surrounding issues would be worked out.
I've posted previously on desktop-devel-list, that I think it'd be far
more sane that 2.32 is 3.0.
Below is a run down of where we are with each component of this work. In
addition to what follows, there's more to do with the PKCS#11 work and
certificate key UI stuff, although this work need not be ready for 3.0.
Secret Service DBus API
-----------------------
An API isn't a worth anything until it's been implemented, and when
designing the Secret Service API, we said we wouldn't pin it down until
it has been implemented at least once.
That was a good plan, because there's much recent reworking of the
design with regards to prompting and long running calls. DBus makes this
very hard and awkward [1], but I believe that we now (as of a week ago)
have a design [2] that works neatly around DBus deficiencies.
gnome-keyring-daemon Implementation
-----------------------------------
The implementation of the Secret Service API in gnome-keyring-daemon is
about 2/3 complete [3]. It's my aim within the next two to three months,
to merge this as master in gnome-keyring. For this reason we haven't
branched gnome-keyring for gnome-2-28.
The problems with long running DBus method calls where holding this up,
but now that we've sorted this out in the Secret Service API we can move
forward again.
libgnome-keyring Library
------------------------
The libgnome-keyring client side of the gnome_keyring_xxx() API will be
split into its own module. It will use the Secret Service API, along
with one or two extra DBus interfaces, to communicate with
gnome-keyring-daemon. It will be ABI compatible with the current
libgnome-keyring which ships as a part of the gnome-keyring module. No
new features are being exposed in libgnome-keyring, and some calls will
be stubbed out.
This work is about 1/4 complete. Various issues to do with transparently
using DBus together with glib mainloops need to be sorted out. The
problems with long running DBus method calls where holding this up, but
now that we've sorted this out in the Secret Service API we can move
forward again.
gsecrets Library
----------------
This will be a new glib based library for use of the Secret Service API.
It will support the new features that the Secret Service API enables.
This component is not even in the design stage yet. In particular I'd
like to only implement this once we get DBus support in glib. Without
that, this will be a mess of incompatible mainloop adapters, duplicated
code, and all sorts of stuff I'm not looking forward to.
Migration and Porting
---------------------
The internal binary protocol which is currently used to communicate with
gnome-keyring will no longer be present.
Because of this the PAM and startup code in gnome-keyring will need to
be redesigned.
Even with the libgnome-keyring compatibility API noted above, many
applications and libraries will need to be ported. In particular some
components have taken it on themselves to try and speak the internal
gnome-keyring binary protocol.
When you get ready for the unexpected, the unexpected gets ready for you.
Cheers,
Stef
[1] http://marc.info/?l=freedesktop-dbus&m=121675537300488&w=2
[2] http://article.gmane.org/gmane.comp.freedesktop.authentication/24
[3] http://git.gnome.org/cgit/gnome-keyring/log/?h=dbus-api
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]