Re: [Evolution-hackers] make check failing in the e-d-s gnome-2-32

2011-06-09 Thread Matthew Barnes
Resending since my original reply never made it to the mailing list for
some reason...

 Forwarded Message 
From: Matthew Barnes mbar...@redhat.com
To: Murray Cumming murr...@murrayc.com
Cc: evolution-hackers@gnome.org, Tristan Van Berkom
trista...@openismus.com
Subject: Re: [Evolution-hackers] make check failing in the e-d-s
gnome-2-32
Date: Wed, 08 Jun 2011 09:32:24 -0400

On Wed, 2011-06-08 at 10:10 +0200, Murray Cumming wrote:
 An environment variable can be set easily, for all tests, and maybe for
 individual tests, like so in addressbook/tests/ebook/Makefile.am:
 
 +test_dir_base = /tmp/ebook-test-yadda/
 +TESTS_ENVIRONMENT = \
 +   XDG_DATA_HOME=${test_dir_base}
 
 However, the necessary value for XX can only be known after the test
 has started, right?

You could probably get away with just using a date stamp instead of
random characters for XX.  The key is really for each address book
to have its own unique ESource ID.  The backend will create a separate
directory per address book under whatever we choose as the base dir.

The tricky part is the D-Bus service is what really needs the custom
XDG_DATA_HOME, since that's where the file backend lives and only it's
supposed to know where the data is really stored.  But unfortunately our
test framework doesn't start the D-Bus service itself -- that's still a
manual step before running the tests.

To really automate the whole thing, the test environment is gonna have
to set up some kind of private D-Bus session and launch the address book
service prior to running the client-side tests, and then clean up after
itself.  I think that's possible but it's a bit beyond my expertise at
the moment.

You can kinda see why I've been dragging my feet about fixing the tests.
Haven't had enough spare cycles to really do it properly.



___
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] IMAP Features plugin -- still useful?

2011-06-09 Thread Matthew Barnes
The IMAP Features (imap-headers) plugin allows you to specify which
headers to download from an IMAP server when building folder summaries.
This is useful for instance when you have client-side filters that
operate on particular headers not normally included in an envelope.  It
appears in the account editor as a tab labeled IMAP Headers.

But the plugin only applies to accounts using the older IMAP provider.
Does this feature also make sense to support in the IMAPX provider, or
should it die out with the older IMAP provider?

___
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] IMAP Features plugin -- still useful?

2011-06-09 Thread Adam Tauno Williams
On Thu, 2011-06-09 at 06:39 -0400, Matthew Barnes wrote:
 The IMAP Features (imap-headers) plugin allows you to specify which
 headers to download from an IMAP server when building folder summaries.
 This is useful for instance when you have client-side filters that
 operate on particular headers not normally included in an envelope.  It
 appears in the account editor as a tab labeled IMAP Headers.
 But the plugin only applies to accounts using the older IMAP provider.
 Does this feature also make sense to support in the IMAPX provider, or
 should it die out with the older IMAP provider?

Slightly confused.  Under Preferences - Mail Preferences - Headers one
can add custom Displayed Message Headers.  At least that works with
IMAPX [probably doesn't involve the plugin].  Doesn't that cause the
header to be downloaded as well?

We use the Displayed Message Headers feature extensively since our
workflow system puts a job/ticket/workorder number in an X- header of
the e-mail's it generates.


___
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] IMAP Features plugin -- still useful?

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 06:53 -0400, Adam Tauno Williams wrote:
 Slightly confused.  Under Preferences - Mail Preferences - Headers one
 can add custom Displayed Message Headers.  At least that works with
 IMAPX [probably doesn't involve the plugin].  Doesn't that cause the
 header to be downloaded as well?

As I understand it, that's merely a UI preference when displaying the
full message content.  Obviously the entire message has to be downloaded
to display the message.

The plugin I'm referring to allows you to download extra headers when
building the table of contents (or summary) of a folder, as shown in
Evolution's top panel, before the full message content + attachments are
downloaded.  It's at this stage that client-side filters are applied to
the folder summary, and filters can be configured to trigger on specific
headers, even custom X- headers.

___
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] make check failing in the e-d-s gnome-2-32

2011-06-09 Thread Raul Gutierrez Segales
Le jeudi 09 juin 2011 à 06:24 -0400, Matthew Barnes a écrit :
 Resending since my original reply never made it to the mailing list for
 some reason...
 
  Forwarded Message 
 From: Matthew Barnes mbar...@redhat.com
 To: Murray Cumming murr...@murrayc.com
 Cc: evolution-hackers@gnome.org, Tristan Van Berkom
 trista...@openismus.com
 Subject: Re: [Evolution-hackers] make check failing in the e-d-s
 gnome-2-32
 Date: Wed, 08 Jun 2011 09:32:24 -0400
 
 On Wed, 2011-06-08 at 10:10 +0200, Murray Cumming wrote:
  An environment variable can be set easily, for all tests, and maybe for
  individual tests, like so in addressbook/tests/ebook/Makefile.am:
  
  +test_dir_base = /tmp/ebook-test-yadda/
  +TESTS_ENVIRONMENT = \
  +   XDG_DATA_HOME=${test_dir_base}
  
  However, the necessary value for XX can only be known after the test
  has started, right?
 
 You could probably get away with just using a date stamp instead of
 random characters for XX.  The key is really for each address book
 to have its own unique ESource ID.  The backend will create a separate
 directory per address book under whatever we choose as the base dir.
 
 The tricky part is the D-Bus service is what really needs the custom
 XDG_DATA_HOME, since that's where the file backend lives and only it's
 supposed to know where the data is really stored.  But unfortunately our
 test framework doesn't start the D-Bus service itself -- that's still a
 manual step before running the tests.
 
 To really automate the whole thing, the test environment is gonna have
 to set up some kind of private D-Bus session and launch the address book
 service prior to running the client-side tests, and then clean up after
 itself.  I think that's possible but it's a bit beyond my expertise at
 the moment.
 
 You can kinda see why I've been dragging my feet about fixing the tests.
 Haven't had enough spare cycles to really do it properly.

For the e-d-s backend in libfolks (not merged into master yet) we do the
following for our tests:

- set XDG_DATA_HOME, XDG_CACHE_HOME and XDG_CONFIG_HOME to a temp dir
- start new session bus
- run tests
- clean up temp dir

Relevant files:

http://cgit.collabora.com/git/user/rgs/folks/tree/tests/eds/Makefile.am?h=eds-0.5
http://cgit.collabora.com/git/user/rgs/folks/tree/tests/tools/with-session-bus-eds.sh?h=eds-0.5
http://cgit.collabora.com/git/user/rgs/folks/tree/tests/tools/eds.sh?h=eds-0.5

Cheers,
Raúl


___
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] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 07:12 -0400, Matthew Barnes wrote:
 Since merging the account-mgmt branch will change nearly all client-side
 APIs in E-D-S including EClient, and since it would be wise regardless
 of my schedule to allow ourselves some extra time to tweak this brand
 new EClient API before pronouncing it frozen, what do you think about
 forcing users of it to acknowledge that the API is still unstable by
 having them do something like:
 
 #define ECLIENT_API_IS_SUBJECT_TO_CHANGE
 #include libecal/e-cal-client.h
 
 and leave that requirement in place until 3.4 or maybe even 3.6?

Hi,
I hope not, I'm currently working on evo bits to be buildable with
E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is
done, but I'm postponing it till I have evo and the standard rest done
as well). Having one API deprecated and second unstable doesn't sound
good to me, same as there doesn't seem to be many things to change
anyway. We can always increase .so name version, that's just for it,
isn't it?
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] New 'eclient' branch in eds

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: 
 I hope not, I'm currently working on evo bits to be buildable with
 E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is
 done, but I'm postponing it till I have evo and the standard rest done
 as well). Having one API deprecated and second unstable doesn't sound
 good to me, same as there doesn't seem to be many things to change
 anyway. We can always increase .so name version, that's just for it,
 isn't it?

Anything in the EClient API dealing with ESourceList, URI strings, or
default sources will be removed when the account-mgmt branch is merged,
and there's a fair chance now that may not happen until 3.3.  So the API
is unstable whether we claim it to be or not.

Obviously we would bump sonames when things change with or without the
#define.  My suggestion was more about setting expectations for users of
the API.  It's a way of saying we think this API is stable but it's
still too soon to know for sure; fair warning.

___
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] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
(I cannot Ctrl+L the message)

On Thu, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote:
 On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: 
  I hope not, I'm currently working on evo bits to be buildable with
  E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is
  done, but I'm postponing it till I have evo and the standard rest done
  as well). Having one API deprecated and second unstable doesn't sound
  good to me, same as there doesn't seem to be many things to change
  anyway. We can always increase .so name version, that's just for it,
  isn't it?
 
 Anything in the EClient API dealing with ESourceList, URI strings, or
 default sources will be removed when the account-mgmt branch is merged,
 and there's a fair chance now that may not happen until 3.3.  So the API
 is unstable whether we claim it to be or not.
 
 Obviously we would bump sonames when things change with or without the
 #define.  My suggestion was more about setting expectations for users of
 the API.  It's a way of saying we think this API is stable but it's
 still too soon to know for sure; fair warning.

It's different, from my point of view, as it's only few functions, with
compare of the whole EClient related API, not talking that it's trying
to be compatible, in this account management area, with the previous
API, where your change just changes core functions. Thus I would keep
this as is.

By the way, thinking of your announcement, I hope you are fine if I'll
finish this stop using deprecated Book/Cal API in evo as soon as
possible and commit it, thus it'll have more testing (I'm pretty sure
I'll introduce few regressions and bugs, even it's more or less monkey
work). As I mentioned couple times on various threads, messages and
maybe also IRC chats, this will make your life pretty harder, as the
change will not be simple, and the initial merge of such change into
your account management branch will be painful.
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


[Evolution-hackers] Rethinking Camel settings

2011-06-09 Thread Matthew Barnes
I'm at the point now with the account-mgmt branch where I have to deal
with the settings that trickle down into the various Camel providers.
The way the settings are managed now is to embed them into the Camel
service's URL string as a list of named parameters.  This is suboptimal
for the same reasons as the free-form ESource property dictionary:

  - All settings have to be manually converted to/from a string, even if
it's a numeric or boolean value.  This is more of a nuisance than a
blocker.

  - No way to query all available settings in a given CamelService
instance, since some parameters may be omitted from the URL string.

  - No way to query the default values for these settings, which is
important for things like the mail account editor.  Assuming FALSE
or NULL or 0 in the absence of a parameter isn't always correct.

  - No nice way to push change notifications for these settings down
to Camel.  In most cases an app restart is required.  That may be
unavoidable for some settings, but we can do better overall.

So I'll be doing away with these free-form URL parameters and converting
them to GObject properties in the various CamelService subclasses, which
addresses all the shortcomings listed above.

Such properties will be tagged with a custom GParamFlag identifying it
as a setting, so it's easy to distinguish setting properties from normal
properties.  I used a similar approach in the new ESource API and it
worked out well.

For now we'll still stuff Camel settings into the URL string that gets
stored in the GConf XML blob, but we'll handle the packing and unpacking
of those URL parameters from Evolution.  Bear in mind the ultimate
destination for those setting values is key files, so Evolution will be
involved in the packing and unpacking of settings eventually anyway.
This is just a temporary stop-gap.

I'm going to do the URL param to GObject property conversion in the
master branch prior to merging the account-mgmt branch.  That will lay
the groundwork for an smooth migration to key files when the time comes.


___
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] New 'eclient' branch in eds

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 18:40 +0200, Milan Crha wrote: 
 By the way, thinking of your announcement, I hope you are fine if I'll
 finish this stop using deprecated Book/Cal API in evo as soon as
 possible and commit it, thus it'll have more testing (I'm pretty sure
 I'll introduce few regressions and bugs, even it's more or less monkey
 work). As I mentioned couple times on various threads, messages and
 maybe also IRC chats, this will make your life pretty harder, as the
 change will not be simple, and the initial merge of such change into
 your account management branch will be painful.

Yes, please do get us using the async EClient APIs in Evolution ASAP.
I can deal with the impact to the branch -- I don't expect it to be too
severe.

___
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] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 13:15 -0400, Matthew Barnes wrote:
 Yes, please do get us using the async EClient APIs in Evolution ASAP.
 I can deal with the impact to the branch -- I don't expect it to be too
 severe.

Thanks, I'll do that. Just the first transition will be about not using
deprecated API, the second part of it, making calls async, is a very
different task, as I go through calendar sources and see all the sync
calls and the API being served synchronously as well. Thus I expect some
design changes will be needed in calendar, to make this work as
intended. Contacts seems mostly fine, for what I touched so far.

It would be nice to have the first part ready for the Monday release,
but I'm not that far yet, thus if no miracle will happen then I've this
done for 3.1.3. Pity for another soname version bump due to API changes
in libedataserverui, which I would prefer to have in once, but...
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] IMAP Features plugin -- still useful?

2011-06-09 Thread Adam Tauno Williams
On Thu, 2011-06-09 at 06:39 -0400, Matthew Barnes wrote:
 The IMAP Features (imap-headers) plugin allows you to specify which
 headers to download from an IMAP server when building folder summaries.
 This is useful for instance when you have client-side filters that
 operate on particular headers not normally included in an envelope.  It
 appears in the account editor as a tab labeled IMAP Headers.
 But the plugin only applies to accounts using the older IMAP provider.
 Does this feature also make sense to support in the IMAPX provider, or
 should it die out with the older IMAP provider?

Slightly confused.  Under Preferences - Mail Preferences - Headers one
can add custom Displayed Message Headers.  At least that works with
IMAPX [probably doesn't involve the plugin].  Doesn't that cause the
header to be downloaded as well?

We use the Displayed Message Headers feature extensively since our
workflow system puts a job/ticket/workorder number in an X- header of
the e-mail's it generates.

___
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] New 'eclient' branch in eds

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 22:48 +0200, Milan Crha wrote:
 Thanks, I'll do that. Just the first transition will be about not using
 deprecated API, the second part of it, making calls async, is a very
 different task, as I go through calendar sources and see all the sync
 calls and the API being served synchronously as well. Thus I expect some
 design changes will be needed in calendar, to make this work as
 intended. Contacts seems mostly fine, for what I touched so far.

Understood.  If we could at least get the contact photo mess fixed up in
the mailer for 3.2 that would be awesome.  It still blocks the UI.

___
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] GOA Integration (was: New 'eclient' branch in eds)

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 21:56 +0100, Philip Withnall wrote:
 I guess this involves updating the Google Contacts address book backend
 to use GOA's OAuth 1.0 magic. I've recently updated libgdata to be able
 to cope with OAuth, and I've got an (untested) patch to e-d-s to update
 it to use libgdata's shiny new authorisation API. Over the next few days
 I intend to test it properly and fix it up.
 
 I hope this fits in well with what you've been conscripted to do re.
 GOA.

Having just started on it this week, so far I'm mostly just concerned
with keeping Evolution synchronized with any Google online accounts.

But yeah, I was hoping libgdata would make things magically work for
address book authentication.  And I think I have a handle on the mail
side -- just need to extend our CamelSASL framework to handle XOAUTH
from outside of Camel.

Google Calendars have me stumped, however, since we defer to our
standard CalDAV backend which authenticates with stored passwords from
the keyring.  I'm not sure how to slip in OAuth integration for this one
special case.

I'm open to suggestions if you have any.

___
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] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 17:07 -0400, Matthew Barnes wrote:
 On Thu, 2011-06-09 at 22:48 +0200, Milan Crha wrote:
  Thanks, I'll do that. Just the first transition will be about not using
  deprecated API, the second part of it, making calls async, is a very
  different task, as I go through calendar sources and see all the sync
  calls and the API being served synchronously as well. Thus I expect some
  design changes will be needed in calendar, to make this work as
  intended. Contacts seems mostly fine, for what I touched so far.
 
 Understood.  If we could at least get the contact photo mess fixed up in
 the mailer for 3.2 that would be awesome.  It still blocks the UI.

I plan that and itip-formatter plugin right after I finish this. I've a
little idea what to do, but will see whether it'll be doable in that
way.

Within the initial changes I already changed some bits, which are
to-be-tested, which might make the canceling working properly for the
addressbook lookup, even when it's stuck. But will see later.

___
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] GOA Integration (was: New 'eclient' branch in eds)

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote:
 Google Calendars have me stumped, however, since we defer to our
 standard CalDAV backend which authenticates with stored passwords from
 the keyring.  I'm not sure how to slip in OAuth integration for this
 one special case.

Hi,
I do not know much background of OAuth, (to be honest, none at all),
thus this is rather a question than answer: CalDAV is using libsoup to
connect to the Google's calendar server and what you are dealing with is
that you do not know how to tell CalDAV to use OAuth and how to pass it
from the UI part to the backend, supposing the libsoup is capable of
this OAuth feature?

If so, then that might be pretty simple with EClient (on actual git
master), just do:
a) in e-client-utils.c::e_credentials_authenticate_helper check for
   which account you are asking credentials and set some key in
   ECredentials to indicate you are offering OAuth token
b) in CalDAV backend, in authenticate_user handler, check for the key
   from a) and pass either user/password or OAuth to libsoup, based on
   its presence.

Hope that helps,
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