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 _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
