Re: [Evolution-hackers] Retiring evolution-exchange

[Matthew Barnes <mbarnes redhat com>]

On Fri, 2012-06-01 at 19:49 +0200, Milan Crha wrote:
> evolution-ews
>    - for 2007,2010 servers (through https, with simpler dependencies)
>    - it's currently semi-maintained
>    - note the EWS implementation on Exchange servers is not feature
>      complete on 2007 servers (I read/saw some articles about it some
>      time ago)

Exchange Web Services is also a publicly documented SOAP API.  Our other
Exchange backends are based on reverse engineering of a proprietary, now
deprecated API (in the case of MAPI) or something that was never really
meant to be an API at all (in the case of OWA).

To me that gives EWS the most staying power going forward.  That's the
one to really focus on.  GNOME is also more deeply invested in it now by
way of GNOME Online Accounts.


> That said, I would deprecate evolution-exchange, but only from active
> maintenance, we still want to support it, as it's proved as working by
> years and its users. The passive maintenance will be only consisting in
> basic functionality testing and making sure it is compileable with
> current eds/evo (testing after changes). I know it's more work for you,
> Matthew, but I also believe that once the API changes will be finished
> (after 3.6.0), the whole passive maintenance will be a toy, with less
> frequent releases than on the other projects.

You sure you want to be dragging around that much redundancy when it's
just you, me and Dan part-time?

I promise I'm not just trying wiggle out of some work I don't want to
do, but I'm trying to think long-term with just us two-and-a-half men.
And I don't see us picking up any other core maintainers any time soon.

I think you're underestimating the maintenance burden, even if we're not
actively fixing bugs anymore.  The client-facing APIs have been stable
and I think even the new ESource APIs are already pretty stable having
refined them for a year and a half.

The backend-facing APIs less so.  They tend to see more churn anyway,
even without my branch.  I can't think of a recent release where the
backend APIs didn't change a little.  And that's fine -- the damage is
contained -- but we still have to go touch all the backends for every
API change and some of those aren't trivial.  And especially with this
new E-D-S architecture I've cooked up, which is an improvement but still
far from perfect, I think we'll be seeing a rash of backend API changes
over the next few devel cycles.  So I'm not really buying the "toy"
argument.

I'm sad to lose the Novell folks but I'm trying to make the best of it
by treating this an an opportunity to dump some old baggage so we have a
leaner code base to focus on, even if that means leaving a few users out
in the cold.  No one is going to seriously criticize us for wanting to
lighten our load after our team just got sliced in half.

To be honest, I was being conservative in suggesting we only cut _one_
Exchange backend loose.

Matthew Barnes