Re: [Evolution-hackers] Rethinking account management

2012-04-30 Thread David Woodhouse 
On Sun, 2012-04-29 at 19:50 -0400, Matthew Barnes wrote:
 It's been awhile since I've posted a progress update on this branch, but
 I just wanted to mention that as of this weekend I think I finally have
 Evolution pretty much wrapped up now and am moving on to the groupware
 modules starting with Evolution-EWS, since I'm also on the hook for
 integrating EWS with the new Exchange support in GNOME Online Accounts.

Yay, good work. Thanks.

When you're doing the groupware back ends, please don't forget the
evolution-activesync is in GNOME git too, now! :)

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2012-04-29 Thread Matthew Barnes 
It's been awhile since I've posted a progress update on this branch, but
I just wanted to mention that as of this weekend I think I finally have
Evolution pretty much wrapped up now and am moving on to the groupware
modules starting with Evolution-EWS, since I'm also on the hook for
integrating EWS with the new Exchange support in GNOME Online Accounts.

I'm sure I'll have more tweaks and bug fixes for Evolution and E-D-S,
especially since I haven't really handled groupware accounts under the
new ESource API yet, although I've tried to anticipate what we'll need.

I already have patches written for the GNOME Shell calendar and GNOME
Panel calendar applets, and have alerted the Telepathy/Folks developers
about the upcoming breaks [1].  I tried to patch the E-D-S Folks backend
myself but my feeble Vala skills just aren't up to the task.

So I think I'm on track to merge this branch during this cycle, though I
dare not predict a merge date just yet.  I think once I finish off EWS
I'll have a much more accurate sense of the remaining work ahead of me.

I rebased both Evo and EDS branches on 3.5.1 today, so feel free to try
them out if you're curious.  Just be cautious of the account migration:
it's a one-way trip.  Maybe test it on a different user account for now.

Matthew Barnes


[1] http://lists.freedesktop.org/archives/telepathy/2012-April/006072.html


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2012-03-01 Thread Matthew Barnes 
I added a page to our wiki about the upcoming file format for account
data.  It focuses more on the nuts and bolts of the file format itself
rather than the APIs used to access the data.  In particular, I wanted
to get the mail account format written down somewhere since it's a bit
more complex than the rest.

http://live.gnome.org/Evolution/ESourceFileFormat

Matthew Barnes

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2012-03-01 Thread Srinivasa Ragavan 
On Thu, Mar 1, 2012 at 8:13 PM, Matthew Barnes mbar...@redhat.com wrote:
 I added a page to our wiki about the upcoming file format for account
 data.  It focuses more on the nuts and bolts of the file format itself
 rather than the APIs used to access the data.  In particular, I wanted
 to get the mail account format written down somewhere since it's a bit
 more complex than the rest.


This is good to have. Lemme go through them to see if I see any issues there

-Srini.

 http://live.gnome.org/Evolution/ESourceFileFormat

 Matthew Barnes

 ___
 evolution-hackers mailing list
 evolution-hackers@gnome.org
 To change your list options or unsubscribe, visit ...
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-09-14 Thread Christian Hilberg 
Hi,

Am Dienstag 18 Januar 2011, um 20:32:44 schrieb Matthew Barnes:
 [...] 
 Now I'll let you in on my master plan:
 
 Either in the 3.2 or 3.4 time frame, after the branch is merged and has
 some time to settle in and stabilize, I want to move these configuration
 dialogs to Evolution-Data-Server and also write some simple command-line
 tools to run the dialogs.
 
 Doing his will finally make it possible to configure address books and
 calendars for E-D-S independently of Evolution.  With that in place, we
 can start adding some nice desktop integration.

Has there already been a manifestation of that Evo-independent backend
configuration?

Kind regards,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-09-14 Thread Matthew Barnes 
On Wed, 2011-09-14 at 11:27 +0200, Christian Hilberg wrote: 
  Doing his will finally make it possible to configure address books and
  calendars for E-D-S independently of Evolution.  With that in place, we
  can start adding some nice desktop integration.
 
 Has there already been a manifestation of that Evo-independent backend
 configuration?

I haven't actually split them off from Evolution yet, but the address
book and calendar configuration modules are here under the book-config
and cal-config directories:

http://git.gnome.org/browse/evolution/tree/modules?h=account-mgmt

They replace the equivalent EPlugins currently on the master branch.
However they require base classes which are not presently in master,
such as ESourceConfig and ESourceConfigBackend.

Making them Evo-independent is just a matter of moving those directories
and required base classes to Evolution-Data-Server.  If there's time
I'll try to do that for 3.4, or I may let them remain in Evolution for
3.4 and move them to E-D-S for 3.6.  We'll see how things play out.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-04-19 Thread Matthew Barnes 
There's a really interesting thread over on desktop-devel-list.  David
Zeuthen is taking on the task of desktop-wide online account management
for GNOME 3.2, with E-D-S integration among other things.

What he's describing sounds like the missing piece in my account
management redesign for dealing with online services and groupware
accounts.  I've already said as much on the list.

Everyone should read this:

http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00107.html

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-03-30 Thread Matthew Barnes 
On Wed, 2011-03-30 at 07:49 +0200, Milan Crha wrote:
 should it delete them too? I've a feeling there is no need for it,
 especially when you want to have them as three separate independent
 objects. But that's just a feeling.

As long as Evolution treats account/identity/transport triplets as a
single unit, I think they should be created and destroyed together.

If and when Evolution allows you to define identities and transports
independently of accounts, then we should reconsider like you said.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-03-29 Thread Matthew Barnes 
In last week's IRC meeting I promised more details about the file format
I'm designing for mail accounts.

I like the way Thunderbird splits accounts, identities and transports
into orthogonal concepts.  Each account has a default identity and
transport, but then you can go back and define additional identities and
transports.  We've had numerous requests for this capability over the
years, but we can't really do it with the current architecture.  Right
now you have to define a complete account for every different identity
you want.  So I'm trying to at least build Thunderbird's flexibility
into the file format, even if Evolution can't yet take advantage of it.

First, to clarify these terms:

Generally, a mail account describes a mailbox on some host that holds
your email.  A mail account object in Evolution will hold authentication
details for accessing that mailbox, and further settings for interacting
with it such as how often to check for new messages, whether to
synchronize the mailbox contents locally for offline viewing, etc.
Eventually I'd like to move new mail notification settings here as well.

A mail identity describes what information recipients will see when they
read your messages.  So things like your name, email address, reply-to
address, signature, etc.  A mail identity object in Evolution will also
describe things that Evolution should do automatically when composing
and sending messages.  This includes signing and/or encrypting outgoing
messages, automatically adding Cc: or Bcc: recipients, what folder to
put sent messages in, etc.  Eventually I'd like to move composer
preferences here as well: things like whether to compose in HTML mode,
preferred reply and forward styles, where to insert the signature, etc.

And last but not least, a mail transport is generally going to describe
an SMTP server and hold authentication details for it.


So.  My plan is for a complete mail account (as Evolution defines mail
accounts currently) to consist of three separate ESource objects, and
hence three separate key files, arranged hierarchically like so:

 +--+
 | Mail Account |
 |   uid: aaa   |
 +--+
/\
   +---+  ++
   | Mail Identity |  | Mail Transport |
   |   uid: bbb|  |uid: ccc|
   +---+  ++

The hierarchy just ensures that deleting the mail account from the
ESource registry will also take out the default identity and transport
for that account.

Here's a skeletal example of all three key files, minus all the extra
options.  Remember that each key file group, other than [Data Source],
is handled by a unique subclass of ESourceExtension.  So all I'm really
doing here is defining new ESourceExtension subclasses for mail stuff.
I'm also reusing existing extensions such as [Authentication] which are
also used in address books and calendars.


Mail Account (uid: aaa)
---

[Data Source]
DisplayName=My Account
BackendName=imapx
Parent=

[Authentication]
Host=my.mail.server.com
Method=ssl
Port=993
RememberPassword=true
User=mbarnes

[Mail Account]
Enabled=true
Identity=bbb# Refers to the default Mail Identity (uid: bbb)

[IMAP+ Backend]
...backend-specific options go here...


Mail Identity (uid: bbb)


[Data Source]
DisplayName=Matthew Barnes mbar...@redhat.com
BackendName=
Parent=aaa

[Mail Identity]
Name=Matthew Barnes
Address=mbar...@redhat.com
ReplyTo=
Organization=
Signature=
Transport=ccc# Refers to the default Mail Transport (uid: ccc)


Mail Transport (uid: ccc)
-

[Data Source]
DisplayName=smtp.mail.server.com
BackendName=smtp
Parent=aaa

# The 'placeholder' key is just that.  Every group needs at least one
# key in order to appear in the key file, but there's nothing really to
# put here at the moment.  A little awkward, but I can live with it.
[Mail Transport]
Placeholder=For future transport options

[Authentication]
Host=smtp.mail.server.com
Method=none
Port=25
RememberPassword=false
User=


With this much figured out, I have removed EAccount and EAccountList
from libedataserver on my account-mgmt branch and am now trudging
through Evolution trying to put it back together using the time-tested
figure the rest out as I go approach.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-03-29 Thread Milan Crha 
On Tue, 2011-03-29 at 09:26 -0400, Matthew Barnes wrote:
 The hierarchy just ensures that deleting the mail account from the
 ESource registry will also take out the default identity and transport
 for that account.

Hi,
should it delete them too? I've a feeling there is no need for it,
especially when you want to have them as three separate independent
objects. But that's just a feeling.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-03-17 Thread Matthew Barnes 
On Tue, 2011-03-01 at 23:02 -0500, Matthew Barnes wrote: 
 My next steps are to write the migration code for all the XML blobs in
 our sources GConf keys, and then it's on to mail accounts.

I rebased the account-mgmt branches [1] again to snapshot my progress.

Address book and calendar migration is done now for both GConf keys and
keyring entries, and I've spent the past week polishing, documenting and
even writing some unit tests (!) for the new ESource class and other
libedataserver APIs.

I also posted browsable documentation for the new APIs here:
http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/

Next, I'm finally moving on to converting mail accounts into ESources.
I have some vague ideas of how this will work, but I don't want to say
too much more until I have a better grasp of just what the heck I'm
getting myself into.

Wish me luck.  I'll report back again once I'm in the thick of it.


[1] http://git.gnome.org/browse/evolution-data-server/log/?h=account-mgmt

http://git.gnome.org/browse/evolution/log/?h=account-mgmt



___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-01-26 Thread Patrick Ohly 
On Do, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
 libebook
 
 - Remove e_book_new_from_uri() and e_book_get_uri().
 
 - Remove e_book_get_addressbooks().
 
 
 libecal
 ---
 
 - Remove e_cal_new_from_uri() and e_cal_get_uri(). 

 - Remove e_cal_get_sources().

I must admit that I haven't read all of the emails due to lack of time.

SyncEvolution uses all of these calls. I don't mind rewriting the code,
but let's make sure that there is a proper replacement.

What I need to do is:
- list all address books and calendars
- open any of the listed databases
- create new ones at a location chose by the user
  (file://path uri in the current API)

Is all of that still going to be possible? How?

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-01-26 Thread Matthew Barnes 
On Wed, 2011-01-26 at 16:23 +0100, Patrick Ohly wrote:
 SyncEvolution uses all of these calls. I don't mind rewriting the code,
 but let's make sure that there is a proper replacement.
 
 What I need to do is:
 - list all address books and calendars
 - open any of the listed databases
 - create new ones at a location chose by the user
   (file://path uri in the current API)
 
 Is all of that still going to be possible? How?

Listing calendars will look something like this:

#include libecal/e-source-calendar.h
#include libebook/e-source-addressbook.h
#include libedataserver/e-source-registry.h

ESourceRegistry *registry;
const gchar *extension_name;
GList *sources;

registry = e_source_registry_get_default ();

/* List all calendars. */
extension_name = E_SOURCE_EXTENSION_CALENDAR;
sources = e_source_registry_list_sources (registry, extension_name);

/* Do something with the list of ESource objects. */

g_list_free (sources);

Other extension names include:

E_SOURCE_EXTENSION_ADDRESS_BOOK
E_SOURCE_EXTENSION_MEMO_LIST
E_SOURCE_EXTENSION_TASK_LIST

No change to the way ECal and EBook objects are opened.

Can you elaborate on the creation use case?  Sounds like you're creating
local data sources on the fly?

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-01-25 Thread Matthew Barnes 
On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote:
 I kinda wanted to tweak the names anyway, so here's my proposal for the
 new D-Bus interface names:
 
   Old: org.gnome.evolution.dataserver.addressbook.BookFactory
org.gnome.evolution.dataserver.calendar.CalFactory
org.gnome.evolution.dataserver.addressbook.Book
org.gnome.evolution.dataserver.calendar.Cal
 
   New: org.gnome.evolution.dataserver.AddressBookFactory.0
org.gnome.evolution.dataserver.CalendarFactory.0
org.gnome.evolution.dataserver.AddressBook.0
org.gnome.evolution.dataserver.Calendar.0
 
 In the future, if we have to break a D-Bus interface again we'll
 increment the digit.  Then if the user upgrades E-D-S to a version that
 implements Calendar.1 but is still running an e-calendar-factory that
 implements Calendar.0, then when Evolution is launched the session bus
 will have to relaunch the upgraded e-calendar-factory binary and the old
 e-calendar-factory process will lose its well-known D-Bus name (at least
 I think that's how it works... in any case, D-Bus knows what to do).
 
 If there's no objections I'd like to get new interface names into 2.91
 now so I can increment the interface versions on my account-management
 branch and not have to worry about this anymore.

Milan reminded me about this today so I went ahead with it.

It turns out just the D-Bus service names need to be versioned, not the
interface names.  But the same rules for incrementing the version apply.

The new names are (with both versions at '0'):

   Bus Name:org.gnome.evolution.dataserver.AddressBook0
   Object Path: org/gnome/evolution/dataserver/AddressBookFactory
   Interface:   org.gnome.evolution.dataserver.AddressbookFactory

   Bus Name:org.gnome.evolution.dataserver.Calendar0
   Object Path: org/gnome/evolution/dataserver/CalendarFactory
   Interface:   org.gnome.evolution.dataserver.CalendarFactory

More details in the commit message:
http://git.gnome.org/browse/evolution-data-server/commit/?id=89b130c3d75cd0fa023af4064b0d0e3ce2147519

Matthew Barnes


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-01-25 Thread Milan Crha 
On Tue, 2011-01-25 at 16:54 -0500, Matthew Barnes wrote:
 The new names are (with both versions at '0'):
 
Bus Name:org.gnome.evolution.dataserver.AddressBook0
Object Path: org/gnome/evolution/dataserver/AddressBookFactory
Interface:   org.gnome.evolution.dataserver.AddressbookFactory
 
Bus Name:org.gnome.evolution.dataserver.Calendar0
Object Path: org/gnome/evolution/dataserver/CalendarFactory
Interface:   org.gnome.evolution.dataserver.CalendarFactory 

Hi,
thanks for doing this. I'm only wondering, why not a dot or dash (if
available for bus names) between the version number and the bus name
itself? Was there anything preventing it to do it that way? (I'm not
much familiar with DBus itself, so please forgive me if this is a lame
question.)
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-01-25 Thread Matthew Barnes 
On Wed, 2011-01-26 at 06:17 +0100, Milan Crha wrote:
 thanks for doing this. I'm only wondering, why not a dot or dash (if
 available for bus names) between the version number and the bus name
 itself? Was there anything preventing it to do it that way? (I'm not
 much familiar with DBus itself, so please forgive me if this is a lame
 question.)

I would've preferred that myself, but apparently D-Bus (or just GDBus)
doesn't like digits after dots.

g_dbus_is_name (blah.blah.Calendar.0) - FALSE

g_dbus_is_name (blah.blah.Calendar0) - TRUE

I guess next time we bump the version you can stick a dash in there if
you want.  Calendar0 and Calendar-0 are equally ugly to me.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2011-01-18 Thread Kip Warner 
On Tue, 2011-01-18 at 14:32 -0500, Matthew Barnes wrote:
 Now I'll let you in on my master plan:

Nice work Matt.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com


signature.asc
Description: This is a digitally signed message part
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-30 Thread Matthew Barnes 
Another status update:

After much consideration I decided to drop GSettings from the equation
and just access key files directly.  The key file part of the design is
working out well but I've been fighting with GSettings every step of the
way.  It's not that that GSettings is bad, but it's very much designed
for dconf and not key files.  Especially the way I'm using key files.

The straw that broke the camel's back was in trying to figure out how to
localize the display names of built-in top-level key files like On This
Computer and On LDAP Servers.  The GSettings API has no equivalent to
g_key_file_get_locale_string() so I was falling back to a similar hacky
solution as e_source_list_ensure_group().  But with GSettings out of the
way we can have the built-in key files translated through intltool just
as we would for desktop files, and call g_key_file_get_locale_string()
to get the appropriate localized display name.

End result (this the 'system' key file):

[Data Source]
Parent=local
DisplayName=Personal
DisplayName[ar]=ﺶﺨﺼﻳ
DisplayName[as]=ব্যক্তিগত
DisplayName[ast]=Personal
DisplayName[be]=Пэрсанальнае
DisplayName[bg]=Лични
DisplayName[bn]=ব্যক্তিগত
DisplayName[bn_IN]=ব্যক্তিগত
DisplayName[ca]=Personal
displayname...@valencia]=personal
DisplayName[cs]=Osobní
DisplayName[cy]=Personol
DisplayName[da]=Personligt
DisplayName[de]=Persönlich
DisplayName[dz]=རང་དོན།
...etc...

I don't have translations yet for the other key files (the translations
I need are all in Evolution, not E-D-S) but you get the idea.  Note the
key file syntax looks normal again and doesn't use GVariant quoting.

Changes to the API I posted earlier [1] are minimal since the GSettings
interaction was pretty well hidden.  Obviously e_source_get_settings()
is gone, as are the schema files.  The schema for a key file group is
instead derived from the GParamSpec structures of the corresponding
ESourceExtension subclass.  More about that later.


[1] http://mail.gnome.org/archives/evolution-hackers/2010-December/msg00030.html

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-21 Thread Milan Crha 
On Mon, 2010-12-20 at 14:17 -0500, Matthew Barnes wrote:
 Since removing an address book or calendar source will be as simple as
 deleting its key file, in theory the backend process should be
 notified of the file deletion event by its ESourceRegistry and can
 then clean up after itself on its own without being told to by the
 client.

Hi,
I like your idea. It might work as long as the backend is running,
otherwise it will not, unless you'll add a listener for this in factory
and run the backend if needed.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-21 Thread Matthew Barnes 
On Tue, 2010-12-21 at 10:14 +0100, Milan Crha wrote: 
 I like your idea. It might work as long as the backend is running,
 otherwise it will not, unless you'll add a listener for this in factory
 and run the backend if needed.

I actually got it working last night for address books, although it
required more API breaks in libedata-book (e_book_backend_remove() no
longer takes an EDataBook or operation ID).

Same type of problem exists now -- if the backend isn't running and you
go into gconf-editor and manually delete source tags, the cache data
for those deleted sources will never get cleaned up.

My thought was, after this is all done and merged and working, to have
the backend processes scan their cache directories at start up and match
the directory names to registered ESources, then clean up the unmatched
orphan directories.  The should fix the out-of-band deletion problem.

We do the same sort of thing for old composer autosave files.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-20 Thread Matthew Barnes 
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
 Overall the changes are having a simplifying effect on the code base,
 but it will introduce an API break of some kind to almost every library
 in E-D-S.  That's what I wanted to talk about here.

Couple more API breaks to mention which turned out to be happy
accidents: we no longer need e_book_remove() or e_cal_remove(),
nor the corresponding D-Bus methods.

Both the e-addressbook-factory and e-calendar-factory processes will
have their own ESourceRegistry instance, and ESourceRegistry monitors
your sources directory for changes and emits source-added and
source-removed signals in response to new or deleted key files.

Since removing an address book or calendar source will be as simple as
deleting its key file, in theory the backend process should be notified
of the file deletion event by its ESourceRegistry and can then clean up
after itself on its own without being told to by the client.

I should get far enough to actually verify that today or tomorrow.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-19 Thread Rob Bradford 

 (I'm leaning away from having URI keys, favoring instead URI components
  as separate keys from which a complete URI string can be formed.)

As someone who's used ESource in the past ..  I always found the old
way of doing it oh-so-confusing. I even added the following code to
dates:


/*
 * Also ensure that the sources contained within this
 * group have an appropriate uri setup. Removing the
 * absolute uri in favour of a relative one.
 */
source_list = e_source_group_peek_sources (group);

for (GSList *source_list_it = source_list; 
source_list_it != NULL;
source_list_it = g_slist_next 
(source_list_it))
{
ESource *source = (ESource 
*)source_list_it-data;

if (g_str_equal (e_source_peek_relative_uri 
(source), ))
{
const gchar *uri = 
e_source_peek_absolute_uri (source);
gchar *path = g_filename_from_uri (uri, 
NULL, NULL);
gchar *base_name = g_path_get_basename 
(path);

e_source_set_absolute_uri (source, 
NULL);
e_source_set_relative_uri (source, 
base_name);

g_free (base_name);
g_free (path);
}
}

g_free (path);
g_free (new_uri);

Cheers,

Rob
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-19 Thread Matthew Barnes 
On Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote:
  Signals:void(*load_error)   (ESourceRegistry *registry,
  GFile *file,
  GQuark error_domain,
  gint error_code,
  const gchar *error_message);
 
 There is obviously a reason why you wrote this .. but I can't see it.
 Why can't you use const GError * here?

I've been second guessing myself on that too.  I think it was because I
was worried someone would write a signal handler that improperly frees
the GError, or propagates it, or some other memory-corrupting operation.
But I guess I was just being overly paranoid.  A const GError should
work fine.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-10 Thread Milan Crha 
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
 As usual this is turning out to be a bigger job than expected, and I'm
 less confident now that I can get this all done by 2.91.90 but I'm still
 gonna try.  The alternative, since I -really- don't want these XML blobs
 creeping into GSettings even temporarily, is to depend on GConf for 3.0
 and then land this stuff (along with Rodrigo's GSettings branch) early
 in 3.1.  Were it not for the pressure to get everything converted in
 time for GNOME 3.0, I would already be retargeting this for 3.1.

Hi,
sounds reasonable, this seems to be quite intrusive change, not only for
evo itself, but for everyone using it, so landing in time of .90 might
be rather bad. Apart of that we have enough such changes in sources
already, counting also gtk3, so I'm 111% for postponing to early 3.1.

 libedataserverui
 
 
 - All e-passwords functions will simply take an ESource instead of
   component and key strings.  Keyring entries will contain the
   UID of the corresponding ESource instead of URI components (we'll
   convert existing keyring entries as part of the migration phase).

It would be good to allow also username changing in EPasswords. It's
very unusual to allow only password entering when most applications are
allowing to change both username and password (I'm not aware of any
other with enter password only functionality at the moment). It seems
to be related, a bit, thus I'm bringing it here.

Also note one thing which might require a bit rewriting. If I recall
correctly you would use the ESource's UID for password storing. The
thing is that evolution allows setting auth-method, which is used as
'component'. The advantage of this is that the ESource for calendar can
share password from mailer (while not knowing the parent source/account
at all), because they are using same 'component' and 'key'. So with your
change in the passwords there should be a knowledge to which account is
this ESource tight (which is not always clear right now?), and this
parent account should be used instead of the actual ESource, right?

I do not want to complicate things much here, though with the change
also user name proposal above it might mean that one wouldn't use
different name for calendar and a different name for mailer with this? I
think we are not using any such approach here anyway, so I'm only
brainstorming here.
Bye,
Milan

P.S.: If you'll be changing API, please change also EIterator API, to
not return 'const' pointers from e_iterator_get. We use to forget to
change this release by release :)

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-10 Thread Matthew Barnes 
On Fri, 2010-12-10 at 11:54 +0100, Milan Crha wrote:
 It would be good to allow also username changing in EPasswords. It's
 very unusual to allow only password entering when most applications are
 allowing to change both username and password (I'm not aware of any
 other with enter password only functionality at the moment). It seems
 to be related, a bit, thus I'm bringing it here.
 
 Also note one thing which might require a bit rewriting. If I recall
 correctly you would use the ESource's UID for password storing. The
 thing is that evolution allows setting auth-method, which is used as
 'component'. The advantage of this is that the ESource for calendar can
 share password from mailer (while not knowing the parent source/account
 at all), because they are using same 'component' and 'key'. So with your
 change in the passwords there should be a knowledge to which account is
 this ESource tight (which is not always clear right now?), and this
 parent account should be used instead of the actual ESource, right?

User name and authentication method will be stored in a key file group,
which defines the following keys (from my notes):

Schema: org.gnome.Evolution.Source.Authentication
--
[extensions/authentication]
--
domain  : 's'   (do we still need this?)
method  : 's'   ('none' means auth not required)
remember-password   : 'b'
user: 's'

Both the user name and authentication method can be changed freely.

For a groupware account that shares authentication details across all
data sources, it would make sense to put the authentication group in the
top-level ESource alongside account details, then have child ESources
for mail accounts, calendars, etc. refer to it.  The keyring entry for
the groupware account would store the UID of the top-level ESource so
the password too can be easily be shared across all data sources.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-12-09 Thread Matthew Barnes 
Here's a progress update on my account management rewrite.

I've been on travel for the past three weeks and still have another week
to go, so I've only been able to work on this in short spurts -- an hour
here, an hour there.  But I've managed to work through all of E-D-S, get
the test-source-combo-box and test-source-selector programs working with
the keyfile-based ESources, and am now plowing my way through Evolution
itself.

As usual this is turning out to be a bigger job than expected, and I'm
less confident now that I can get this all done by 2.91.90 but I'm still
gonna try.  The alternative, since I -really- don't want these XML blobs
creeping into GSettings even temporarily, is to depend on GConf for 3.0
and then land this stuff (along with Rodrigo's GSettings branch) early
in 3.1.  Were it not for the pressure to get everything converted in
time for GNOME 3.0, I would already be retargeting this for 3.1.

Overall the changes are having a simplifying effect on the code base,
but it will introduce an API break of some kind to almost every library
in E-D-S.  That's what I wanted to talk about here.

I'm still only on address books and calendars.  For mail accounts,
EAccountList will die and EAccount will be split into two separate key
files (one for store settings, one for transport settings).  Beyond
that I don't anticipate many (if any) more API breaks in E-D-S for mail
accounts.

For address books and calendars, ESourceList and ESourceGroup will die
(replaced by an ESourceRegistry singleton which holds everything).  The
ESource API will be rewritten from scratch, will no longer use GConf and
also will no longer have a URI.  All other API breaks follow from that.

So here's what I've broken on my branch so far, grouped by library:


libedataserver
--

- Remove ESourceList and ESourceGroup.

- Rewrite ESource from scratch.


libebook


- Remove e_book_new_from_uri() and e_book_get_uri().

- Remove e_book_get_addressbooks().


libecal
---

- Remove e_cal_new_from_uri() and e_cal_get_uri().

- Remove e_cal_get_sources().

- ECalAuthFunc: the 'key' argument is no longer used.


libedata-cal


- Remove e_cal_backend_get_uri().


libedataserverui


- All e-passwords functions will simply take an ESource instead of
  component and key strings.  Keyring entries will contain the
  UID of the corresponding ESource instead of URI components (we'll
  convert existing keyring entries as part of the migration phase).

- ESourceComboBox will take an ESourceRegistry and an extension name
  as constructor arguments.  The given extension name will filter the
  sources shown in the widget (e.g. address-book, calendar, etc.).

- Similarly for ESourceSelector.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-11-15 Thread Matthew Barnes 
Let's talk D-Bus.

I've started integrating the redesigned, key-file based ESource APIs in
a branch of Evolution-Data-Server and so far it's actually simplifying
the affected code.  I'm leaving mail aside for now and just focusing on
calendars and address books.

I'm gonna have to remove some functions from libebook and libecal which
don't make sense anymore.  More about those later.  But I also realized
I'm gonna have to change the getCal() and getBook() D-Bus methods.

I was a bit horrified to realize over the weekend the way we select a
backend from the factory processes when requesting a new EBook or ECal.
We convert an ESource object to XML and transmit the -entire- XML string
over D-Bus, only to have the factory process reconstruct the ESource
object from the XML string, extract the URI string from the ESource
object, and extract the scheme from the URI.  The scheme is used as a
hash table key for registered backends.

Holy convoluted design, Bat Man!

With the new APIs, apart from GConf migration we won't be constructing
ESources from XML anymore.  So here's how it's gonna work: getCal() and
getBook() will just take the ESource's UID string, the factory process
will look up the corresponding ESource object from its own registry and
call e_source_get_backend() to get the hash table key.  Done.

That part's easy.  What I'm concerned about is avoiding a repeat of the
issues we encountered last cycle when we changed the local backend name
from file to local.  In particular, we need to make sure the client
and servers are using the same D-Bus API at run time.  This is proving
to be a real problem as users upgrade from Evolution 2.30 to 2.32 but
leave the factory processes from 2.30 running.

There's some debate about the best way to handle D-Bus API changes, but
after talking to a few colleagues it seems the simplest approach is to
append a digit to the interface name, like we do for shared libraries.

I kinda wanted to tweak the names anyway, so here's my proposal for the
new D-Bus interface names:

  Old: org.gnome.evolution.dataserver.addressbook.BookFactory
   org.gnome.evolution.dataserver.calendar.CalFactory
   org.gnome.evolution.dataserver.addressbook.Book
   org.gnome.evolution.dataserver.calendar.Cal

  New: org.gnome.evolution.dataserver.AddressBookFactory.0
   org.gnome.evolution.dataserver.CalendarFactory.0
   org.gnome.evolution.dataserver.AddressBook.0
   org.gnome.evolution.dataserver.Calendar.0

In the future, if we have to break a D-Bus interface again we'll
increment the digit.  Then if the user upgrades E-D-S to a version that
implements Calendar.1 but is still running an e-calendar-factory that
implements Calendar.0, then when Evolution is launched the session bus
will have to relaunch the upgraded e-calendar-factory binary and the old
e-calendar-factory process will lose its well-known D-Bus name (at least
I think that's how it works... in any case, D-Bus knows what to do).

If there's no objections I'd like to get new interface names into 2.91
now so I can increment the interface versions on my account-management
branch and not have to worry about this anymore.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-11-15 Thread Milan Crha 
Hi,

On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote:
 I was a bit horrified to realize over the weekend the way we select a
 backend from the factory processes when requesting a new EBook or ECal.
 We convert an ESource object to XML and transmit the -entire- XML string
 over D-Bus, only to have the factory process reconstruct the ESource
 object from the XML string, extract the URI string from the ESource
 object, and extract the scheme from the URI.  The scheme is used as a
 hash table key for registered backends.

Well, it's not complete, the reconstructed ESource is passed into
e_data_book_new, so the backend can access it and knows where to
connect.

 With the new APIs, apart from GConf migration we won't be constructing
 ESources from XML anymore.  So here's how it's gonna work: getCal() and
 getBook() will just take the ESource's UID string, the factory process
 will look up the corresponding ESource object from its own registry and
 call e_source_get_backend() to get the hash table key.  Done.

That's kinda limiting, isn't it? As you allow only saved sources to be
opened, though for example all test suits are not saving their sources,
but just construct them on the fly and pass them to the factory.

 ...
 If there's no objections I'd like to get new interface names into 2.91
 now so I can increment the interface versions on my account-management
 branch and not have to worry about this anymore.

Sounds fine to me.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-11-11 Thread Andrew McMillan 
On Wed, 2010-11-10 at 16:20 -0500, Matthew Barnes wrote:
 On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote:
  Does this mean (for example) that we will be able to have a caldav
  server, with credentials, and then just associate (and maybe
  auto-discover) all of the user's addressbooks, calendars, todo-lists and
  journals which the user has on that server?
 
 I honestly don't know if that's possible with a CalDAV server (I'm just
 not familiar enough with CalDAV), but if we're talking about a groupware
 service...

Yes, it is.  Apple iCal (for example) will discover and show all of a
user's calendar collections.  The contacts app on an iPhone (with iOS
4.1) will discover and show all of a user's addressbooks if that DAV
server also does CardDAV.  Calendar collections may very well also store
VTODO and VJOURNAL data (DAViCal does, for example, as well as
supporting CardDAV in very recent versions).

So Evolution, with SMTP, IMAP, CalDAV and CardDAV servers really is a
complete groupware service.

Newer extensions to CalDAV/CardDAV also add support for service
discovery through SRV lookups for _caldav, _caldavs, _carddav, _carddavs
services and URL locating through requests against /.well-known/carddav
or /.well-known/caldav URLs after the server discovery.


 Currently each of our groupware backends has to invent this kind of
 account management for itself.  All I'm proposing is a general framework
 that backends can utilize to make it easier and more consistent.
 
 Auto-discovery is also up to each backend to implement, and rightfully
 so.  But the framework certainly allows for discovered data sources to
 be associated with the account.
 
 I hope I answered your question.  Like I said, handling of groupware
 accounts is still kinda hand wavy at this point.

I think so.  Evolution was early to the party when CalDAV came out as a
specification, but the support in there has not evolved very well to
follow the current possibilities.

That said, the biggest complaint I hear about Evolution's CalDAV support
is it's lack of a useful 'offline' mode.

I'm currently in the process of developing caldav/carddav setup and
synchronisation process (for another purpose) but once that's working it
might be worth looking at that with a view to seeing if we can improve
the structure of CalDAV setup within Evolution.

I know Milan has done some good work on CalDAV (and I'm very grateful
for it) but I think the area needs some significant refactoring in the
configuration and discovery parts.  My biggest annoyance in there is
that I go into a calendar and add a CalDAV server, and a collection, and
then I go into tasks and add *the same* server, and *the same*
collection, and then I go into Notes and add *the same server* and *the
same collection* and then I go into the addressbook and add *the same
server*, and (phew!) a different collection.

There seems a little redundancy in that process, not least because for a
given server I can discover all of a user's calendars and addressbooks,
and whether they support calendar, tasks and/or notes by making two
PROPFIND requests.  Or maybe three requests, for a more recent server
that allows discovery of the principal URL.

Cheers,
Andrew.
-- 

http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora  Phone: +64(272)DEBIAN
The real problem with hunting elephants is carrying the decoys.




signature.asc
Description: This is a digitally signed message part
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-11-10 Thread Matthew Barnes 
On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote:
 Does this mean (for example) that we will be able to have a caldav
 server, with credentials, and then just associate (and maybe
 auto-discover) all of the user's addressbooks, calendars, todo-lists and
 journals which the user has on that server?

I honestly don't know if that's possible with a CalDAV server (I'm just
not familiar enough with CalDAV), but if we're talking about a groupware
service where, for example, suppose I have a Microsoft Exchange account
consisting of an email store, a calendar, a to-do list and a couple
address books; then with this proposal we can now express a hierarchical
relationship between those different data sources and treat them within
Evolution as a single account, such that I can disable or delete my
Exchange mail account in Preferences and all the other data sources for
that account will automatically follow.

Currently each of our groupware backends has to invent this kind of
account management for itself.  All I'm proposing is a general framework
that backends can utilize to make it easier and more consistent.

Auto-discovery is also up to each backend to implement, and rightfully
so.  But the framework certainly allows for discovered data sources to
be associated with the account.

I hope I answered your question.  Like I said, handling of groupware
accounts is still kinda hand wavy at this point.  Gotta get the simple
cases working first.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Rethinking account management

2010-11-10 Thread Milan Crha 
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote:
 Here's a few built-in top-level stub sources as trivial examples.  They
 don't do anything other than name a backend.  They would appear as bold
 group names in a source selector widget.
 
   1. Filename/UID: on-this-computer
 
  [source]
  name='On This Computer'
  backend='local'
 
 
 The built-in system (a.k.a. Personal) source is an interesting corner
 case because it defines several different groups.  (The comments below
 are just my annotations, they would not appear in the key file.)
 
   Filename/UID: system
 
   [source]# org.gnome.Evolution.Source
   name='Personal'
   parent='on-this-computer'
   
   [extensions/address-book]   # org.gnome.Evolution.Source.Selectable
   color='#00' # would not be used in the UI
   enabled=true# would not be used in the UI
 
   [extensions/calendar]   # org.gnome.Evolution.Source.Selectable
   color='#becedd'
   enabled=true
 
   [extensions/task-list]  # org.gnome.Evolution.Source.Selectable
   color='#becedd'
   enabled=false
 
   [extensions/memo-list]  # org.gnome.Evolution.Source.Selectable
   color='#becedd'
   enabled=false

Hi,
it's pretty confusing to me. I understand from the above that there are
two files, one for groups, which is stored in system directory, and
one for real sources, which is stored in user's home.

Will be there any kind of property inheritance? As in your example
above, I would like to define the 'color' in the [source]
key-file-group, thus all extensions will inherit it, but, if user
changes color for one of them, then it'll create its own key and it will
be used instead of the parent's.

Maybe it's not the best example with the color, but imagine the Exchange
account, I would like to define server address and credentials,
connection setup and such, in the parent, and the children
(mail/calendar/...) will inherit this.

It seems to me that there is no difference between the file in system
and home directory, both are using [source], but each for a different
purpose. I do not think it may work well.

Imagine the exchange account again. Right now you define an account
name, and this name is used as a source group name in Calendar and such,
same as in mailer. With that you wrote I do not see a way of achieve
that just from the user's home. Or is this based on the existence of the
parent/backend key in the [source] key-file-group? In that case the
exchange account will have actually two files instead of one in the home
directory, one for group definition and one for real sources? It's
unnecessary, right? a) you would search for parents, in home and in
system directory. b) you should be able to easily distinguish between
group definitions and real sources definitions (all are named [source]
in your proposal) and be able to _easily_ reconstruct them.

Well, it's not straightforward, from my point of view. I would rather
name groups [group], avoid confusion, and be able to define all this in
one file, thus for usual user they will be able to distribute only one
file with predefined account settings instead of many. Of course, the
groups should either have the 'uid' defined in the file, or it should
inherit uid from the file name itself.

Filename: excha...@my-company

[group]
name='excha...@my-company'
backend='exchange'
server='my-company'
username='me'

[source]
color='#FEFEEF'
parent='excha...@my-company'

[extensions/mail]
enabled=true

[extensions/addressbook]
fragment='personal/Contacts'
name='Contacts'

[extensions/addressbook]
fragment='personal/second-contacts'
name='second-contacts'

[extensions/calendar]
fragment='personal/Calendar'
name='Calendar'
last-notified='2010-10-10T10:10:10'

[extensions/calendar]
fragment='personal/second-calendar'
name='Second Calendar'
color='#80FF80'

...

Well, you cannot have two groups with the same name in the key file,
thus you really meant to have one file per each ESource/EAccount + one
file for the group definition, all these put into one folder in the home
(+ system group definitions in system folder)? I do not like the idea
much, but I agree it can work.

Also, remember that users can name their accounts whatever they want,
but not every latter is usable for the filename - so the files will be
either meaningless strings or something descriptive?

The last two questions (and I see I mostly answered above questions
myself), how will be the group definition propagated to mailer,
respectively how will be defined the POP account, which doesn't have a
group in the folder tree, same as the mbox, which is hacked in and
hidden in the background? Will these two kinds also require its own
group file (for the 'backend' key) or not?

Because you have [source] for groups and [source] for pseudo-sources
(the real source is at the [extension/...]), then will I be able to
define a child of the source, not of the group, and it'll be propagated
to the UI? Just an