CamelDataWrapper: Keep contents in a GByteArray.

Keep CamelDataWrapper contents in an internal GByteArray rather than a
CamelStream.  The CamelStream was causing problems because it now needs
to be seekable, but in some cases we were getting a CamelStreamFilter
which is _not_ seekable.

Also add camel_data_wrapper_get_byte_array() for when you need direct
access to the contents.  This is sometimes more convenient than copying
it into a memory stream, but carries a thread-safety risk if you're not
careful.  Only CamelDataWrapper subclasses should really be using it.

This is another API and ABI break since CamelDataWrapper's CamelStream
pointer was a public struct member.

Remove camel_stream_printf().

GIO streams have no equivalent method, so removing this function forces
our code to look a bit more like it will when we move to GIO streams.

Also, camel_stream_printf() lacks GCancellable and GError arguments,
which inevitably leads to poor error handling in the providers.

libcamel soname has already been bumped for 3.1.4.

Avoid camel_stream_printf().

camel_stream_printf() is next on the chopping block.

Use g_strdup_printf() or a GString to construct a formatted string in
memory, pass to to camel_stream_write() in one go, and then check for
errors (unless it's a memory stream).

post release version bump

News update for 3.1.3.1 release

Updated Spanish translation

Update Simplified Chinese translation.

Bug#654054 Fix eds build failure

camel_stream_vprintf() doesn't exist.

Remove its declaration from camel-stream.h.

Remove camel_stream_reset().

All use cases accounted for; they're all seekable streams, so use
g_seekable_seek() instead if you need to reset the cursor position.

Obviously an API break.  The libcamel soname has already been bumped for
3.1.4 so we'll leave it be.

Prefer g_seekable_seek() over camel_stream_reset().

When a stream is obviously a file or memory stream (both of which
implement the GSeekable interface), use g_seekable_seek() instead of
camel_stream_reset().

This is helping me discover if it's safe to remove camel_stream_reset().
We want to eventually move to GIO streams, which have no reset method.

Camel: Remove some unnecessary type casts.

CamelImapWrapper: Use GError instead of errno.

camel_stream_process_connect(): Add GError parameter.

Updated Galician translations

camel_tcp_stream_ssl_enable_ssl(): Add GError parameter.

SMTP: Use GError instead of errno.

NNTP: Remove unnecessary <errno.h> includes.

POP3: Use GError instead of errno.

[l10n] Updated German translation

[l10n] Updated German translation

Camel: Fix Gtk-Doc notation in comment blocks.

Authorization domains are no longer used in password storage.

They are a relic of keyfile-based password storage, where the auth
domain was merely the keyfile group name.  Keyring-based password
storage, which we now use exclusively, has no such concept.

Rename all "component_name" parameters in e-passwords.c to "unused" and
remove their argument guards from functions.

Remove all AUTH_DOMAIN definitions from ECredentials.  Better to nip
that in the bud before we're stuck with those symbols.  DO NOT bump the
libedataserver soname, however, since that would be highly disruptive to
distros and nothing uses ECredentials yet.

Remove the "domain" parameter from CamelSession password methods.  Also
remove any mention of "auth_domain" URL parameters.  This is a genuine
API break requiring a libcamel soname bump, but no one cares.

post release version bump

News update for 3.1.3 release

Updated Galician translations

libedata-cal cleanups.

Fix build break (my bad).

Update API documentation.

Coding style and whitespace cleanups.

Bug #650671 - Service connect/disconnect not cancelled properly

Require libgdata >= 0.9.1 for GNOME Online Accounts support.

Appearently there were more API changes since libgdata 0.9.0.

Bug #653476 - icaltimezone not copied completely with libical 0.43

This is based on Chen's findings and initial patch for the issue.
Once eds will depend on libical 0.46 this can be removed.

Updated Swedish translation

Bug #650126 - Add API to set the scroll policy of the Contacts container

Bug #653385 - ldaps fails with server using self-signed certificate

Bump the required version of Vala for the bindings.

Closes: bgo#651722 - EDS vala bindings require newer version of Vala

e_cal_client_get_object() should not return VCALENDAR components

The e_cal_get_object() returns either detached instance, the master
object or the first object from the VCALENDAR component, thus make
ECalClient do this too.

This was discovered while fixing regression crash from bug #579779.

Updated Dutch translation by Hannie Dumoleyn

Minor compiler warning fix (change #if to #ifdef)

Bug #224687 - Skip ignored destinations in destination_get_address()

Fix LDAP authentication and process authentication requests on idle

Add OAuth support to Google Contacts backend.

For ESources tagged with a "goa-account-id" property set by Evolution,
authenticate using OAuth 1.0 via libgoa-1.0 and libgdata 0.9.

libedata-book cleanups.

Minor compiler warning fix (change #if to #ifdef)

Bug #224687 - Create lists of lists

Vala bindings: we depend on gio-2.0

Allow asynchronous retrieval of EClient capabilities for easier caching

Fix build breaks when using libgdata 0.9.

Remove pointless ENABLE_THREADS define.

Of course we enable thread support.  We love threads!  And lots of
complex mutex locking!  It's great job security.  </sarcasm>

Introspection: fix annotation in e_vcard_add_attribute

Introspection: fix annotation in e_vcard_get_attribute

SMTP: Handle 235 code after initial AUTH command.

The server may accept the initial response in our AUTH command and
return a 235 (success) code without a 334 (continue) code, such as
for example with XOAUTH.  Handle this correctly.

Make Camel's SASL framework more extensible.

Gather SASL mechanism names by traversing subclasses of CamelSasl
instead of hard-coding all known mechanism names.  This allows
mechanisms to be added from outside of libcamel.

This adds a CamelServiceAuthType pointer to CamelSaslClass, which
changes the ABI.  Statically registered subclasses can just point to a
static CamelServiceAuthType struct.  Dynamically registered subclasses
should allocate a CamelServiceAuthType struct in their base_init class
method and free it in their base_finalize class method.

Adapt CamelSasl subclasses to the new approach.

CamelSasl: Coding style cleanups.

Fix a few srcdir != builddir issues

jhbuild will be defaulting to this soon.

Keep opening EClient-s till they report busy error

Make loading of ENameSelector on demand and cancellable

Reverting one line I added to Christophe's commit on my own

I added this change to Christophe's commit myself, and I didn't
notice that it is unnecessary change, thus I'm reverting it back.
Christophe notified me about my fault in bug #652173.

Bug #652173 - libebook: Delay client-side vCard parsing

Updated Galician translations

Bug #648468 - POP3 doesn't recover or claim error after lost connection

Bug #269413 - Search treats "4 weeks" and "1 month" as synonymous

Updated Slovenian translation

Updated Spanish translation

Bug #565961 - Crash with recurring all-day event

Fix few memory leaks

Emit notification for EClient::opened property

From introspected bindings (i.e.: Vala) we can't
see the opened signal cause it overlaps with the
opened property. So we need to listen to notifications
on the property related to the signal.

Fix sqlitedb-test build error.

EBookBackendSqliteDD: Fix a missing comma in search contacts.

Bug #652530 - EClient - Notify about opening phase result first

Fix recently introduced compiler warnings in CalDAV calendar backend

Bug #652392 - Port to libgdata 0.9.0

Do not use deprecated EBook/ECal API

Post-release version bump.

Gtk-Doc updates.

NEWS update for 3.1.2 release.

Coding style and whitespace cleanups.

EBookBackendSqliteDB, e-sqlite3-vfs.[ch]: Add sqlitedb cache for addressbook. It can
be used as summary+cache.

CamelImapStore: Remove unused declarations.

CamelIMAPXFolder: Fix handling of "filter_junk" option.

Looks like a typo.  Just stumbled on this by accident, but I wonder
if it has something to do with certain junk filtering bugs I've seen
reported by IMAPX users.

Fixup markup of e_vcard_attribute_add_param (takes ownership of param)

Annotate e_vcard_attribute_new (group name may be null)

Use the right free function in the boxed type for EVCardAttributeParam

We were using e_vcard_attribute_free, not e_vcard_attribute_param_free

Added UG translation

Updated Norwegian bokmål translation

CamelVeeFolder: Check for the presence of unmatched folder before
accessing full_name, error in previous commit.

CamelVeeFolder: Adapt changes to unmatched_check_uid that was missed in commit -
6bc75c47f516301364d653140fcf82193d0a2d52 .

CamelVeeFolder: Fix a hang in folder_change_change. do not read db in between a transaction

calendar: include rid in "objects-removed" ECalView signal

Since migration to D-Bus for libecal<->EDS communication, the
RECURRENCE-ID (rid) has not been sent in the "objects-removed" signal.
As a result, a backend could not communicate the removal of specific
recurrences.

This patch adds the rid after a newline to the string stored
internally and transferred via D-Bus. Because the newline is only
added when needed, traditional uid-only removals look the same as
before and continue to work with older versions of libecal. A uid+rid
combination will look like an unknown uid to an older libecal which
does not know how to split them. Therefore the D-Bus API is considered
unchanged and the interface number is not increased.

Whether clients really interpret "objects-removed" with empty rid (=
parent removed) or valid rid (= child removed) correctly is outside
the scope of this patch.

calendar file backend: support remove with CALOBJ_MOD_ONLY_THIS

Support for this capability is easy:
- report removal of the detached recurrence
- report error when not found
- avoid modifying the parent (= full_object)

calendar file backend: removal notification for detached recurrence, part 2

e_cal_remove_object_with_mod() can only return one pair of old/new
object pointers to the caller. When the function modifies the parent
and removes a detached recurrence, the removal of the detached
recurrence had to be deduced by clients from the modification of the
parent.

Now clients are explicitly informed about removal of the detached
recurrence in addition to the modification of the parent.

calendar file backend: removal notification for detached recurrence, part 1

If e_cal_remove_object_with_mod() was called for an appointment where
only a detached recurrence existed, no "objects-removed" signal was
triggered although it should have been.

Apparently Evolution avoids the problem by calling
e_cal_remove_component() instead in this case. Fixing the problem
makes writing clients easier (no special cases).

With this patch, remove_instance() itself decides what it reports back
to the caller. Note that it cannot report back both a modification and
a removal at the moment.

calendar file backend: white list check for supported CalObjModType

Explicitly check that the CalObjModType is supported before
starting to work on the appointment. Relies in libecal to reject
completely bogus modes with an "invalid parameter" error.

libecal: catch invalid CalObjModType values

This protects backends without their own parameter checking
from being invoked with invalid CalObjModType values. Note
that this only excludes values that haven't been defined.
Backends still need to check whether they support the
selected mode.

libecal: added CALOBJ_MOD_ONLY_THIS

The goal is to have an orthogonal API where each operation also
has an inverse operation. Adding a detached recurrence was
possible with e_cal_modify_object(), but removing it again
wasn't without modifying the parent appointment.

CALOBJ_MOD_ONLY_THIS in e_cal_remove_object_with_mod() provides
that inverse operation by avoiding the modifications to the
parent.

The semantic in e_cal_modify_object(), the other call taking a
CalObjModType, is unchanged. CALOBJ_MOD_ONLY_THIS is not valid there.

Because not all backends reject CALOBJ_MOD_ONLY_THIS when they don't
support it, a static capability CAL_STATIC_CAPABILITY_REMOVE_ONLY_THIS
is added that must be checked first before using CALOBJ_MOD_ONLY_THIS.

calendar file backend: support removing parent event with CALOBJ_MOD_THIS

It was possible to create a meeting series with just a detached event
(RECURRENCE-ID set) by importing a meeting invitation for that single
recurrence. It was not possible to arrive at that same state after
adding the parent event (the one with the RRULE) because
e_cal_remove_object_with_mod() removed all instances for
CALOBJ_MOD_THIS and empty rid.

This contradicts the intended semantic of e_cal_remove_object_with_mod():
 "By using a combination of the @uid, @rid and @mod
 arguments, you can remove specific instances. If what you want
 is to remove all instances, use e_cal_remove_object instead."

This patch implements the desired semantic:
- e_cal_backend_file_remove_object(CALOBJ_MOD_THIS) now always
  calls remove_instance().
- remove_instance() was extended to also work for the parent
  event.
- That call removes the complete object if nothing is left
  after removing the instance. This case must be handled by
  the caller. The return value is the original object (if
  it still exists) and NULL if not.
- Because the uid pointer into the object may become invalid
  as part of the removal, a more permanent pointer has to
  be provided by the caller.

Updated Norwegian bokmål translation

e_book_backend_file_get_contact_list: Fix memory leak

vcard_dbt.data should be freed if it is not appended to
the contact list otherwise memory gets leaked.

e_contact_name_from_string(): Fix possible memory leak

The 'name' variable memory was leaked when name_str
is NULL.