Re: [Evolution-hackers] Retiring evolution-exchange
On Thu, 2012-05-24 at 16:15 -0400, Matthew Barnes wrote: The release of Evolution-ActiveSync brings the number of Evolution Data Server backend modules for Microsoft Exchange up to four. Even if we had the manpower to adequately maintain all these, which we don't, four different backends for one product is getting ridiculous. Therefore I think it's time to retire Evolution-Exchange. That module has seen steadily decreasing maintenance for several years, the newest version of Exchange it supports is now a decade old, and frankly it was never all that reliable anyway. As with any Free Software project, retiring Evolution-Exchange simply means we will cease issuing new tarballs. 3.4.x will be its last stable release series. Any interested party is of course welcome to resurrect the project and issue new releases. Sorry for getting back a little late. I will include the reply with regards to evolution-groupwise as well. Though we have several packages that are supporting exchange. If we take a deeper look into what versions of exchange server they support, we might get a clear idea whether we want to retire them or not. evolution-exchange - best backend to support Exchange 2003 servers. There are some enterprises who are using evolution-exchange. As evolution-exchange has been well tested in different Exchange 2003 setups, it would be better bet over evolution-mapi. evolution-mapi, evolution-ews, evolution-activesync - all support 2007 2010. evolution-ews is good on desktops and evolution-activesync is good for mobile clients. We started evolution-ews considering that mapi would be deprecated in future. Then why not retire evolution-mapi instead of evolution-exchange ? I do understand that you looked at the code updates and available developers to decide. It would also be good if we choose what to support based on, what would work as a good enterprise solution. I say enterprise since we are here talking about exchange and groupwise. W.r.t evolution-groupwise, it would be good to continue it until this release. I second the reason which Akhil has mentioned in another email. We would also need to give it sometime to see if there are people interested in contributing there. Thanks, Chenthill. If we have consensus on this I will announce it. At this time I have no plans to adapt the module to the upcoming API changes. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Retiring evolution-exchange
On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: Then why not retire evolution-mapi instead of evolution-exchange ? I hadn't considered that. I'll defer to Milan to make that call. I thought evolution-mapi worked with Exchange 2003 servers at least in theory; I don't know how much actual testing that's had. And I know Milan has been maintaining evo-mapi more actively than evo-exchange and has a good working relationship with the OpenChange developers. In any case, maintaining this many different backends for Exchange is ridiculous and we need to drop at least one of them given our manpower shortage. I guess I don't care so much which, and am probably not the most qualified to choose. What do you think, Milan? I do understand that you looked at the code updates and available developers to decide. It would also be good if we choose what to support based on, what would work as a good enterprise solution. I say enterprise since we are here talking about exchange and groupwise. W.r.t evolution-groupwise, it would be good to continue it until this release. I second the reason which Akhil has mentioned in another email. We would also need to give it sometime to see if there are people interested in contributing there. The thing is, all of these modules are going to require significant work to adapt to the branch I'm about to merge -- groupwise perhaps even more than the rest -- and given that I don't even have access to a GroupWise server to test the changes I'll have to make to it, I'm highly resistant to bothering with it if it's not going to have a full-time maintainer going forward. If someone were to step forward as at least a short-term maintainer that could help test the changes, I would reconsider. I will, however, release an evolution-groupwise 3.5.2 with the changes you made recently for it. That's a fair request. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Retiring evolution-exchange
On Fri, 2012-06-01 at 06:57 -0400, Matthew Barnes wrote: On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: Then why not retire evolution-mapi instead of evolution-exchange ? I hadn't considered that. I'll defer to Milan to make that call. I thought evolution-mapi worked with Exchange 2003 servers at least in theory; I don't know how much actual testing that's had. And I know Milan has been maintaining evo-mapi more actively than evo-exchange and has a good working relationship with the OpenChange developers. In any case, maintaining this many different backends for Exchange is ridiculous and we need to drop at least one of them given our manpower shortage. I guess I don't care so much which, and am probably not the most qualified to choose. What do you think, Milan? I do understand that you looked at the code updates and available developers to decide. It would also be good if we choose what to support based on, what would work as a good enterprise solution. I say enterprise since we are here talking about exchange and groupwise. W.r.t evolution-groupwise, it would be good to continue it until this release. I second the reason which Akhil has mentioned in another email. We would also need to give it sometime to see if there are people interested in contributing there. The thing is, all of these modules are going to require significant work to adapt to the branch I'm about to merge -- groupwise perhaps even more than the rest -- and given that I don't even have access to a GroupWise server to test the changes I'll have to make to it, I'm highly resistant to bothering with it if it's not going to have a full-time maintainer going forward. If someone were to step forward as at least a short-term maintainer that could help test the changes, I would reconsider. I can provide you the support. I will be getting into the new project coming Monday. I can keep myself involved during free time after a couple of weeks time.. - Chenthill. I will, however, release an evolution-groupwise 3.5.2 with the changes you made recently for it. That's a fair request. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Retiring evolution-exchange
On Fri, 2012-06-01 at 08:39 -0600, Vibha Yadav wrote: On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: I can provide you the support. I will be getting into the new project coming Monday. I can keep myself involved during free time after a couple of weeks time.. I can also contribute in my free time as well for GroupWise. As exchange, EWS and GroupWise are good enterprise solutions for Evolution. Fair enough. I'll try to make the necessary changes some time after the merge and then hand it off so you guys can tell me what I broke. :) Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] A better mail formatter
Hi, I've spent last few weeks re-working the email formatter and I think it's finally ready for landing to master. Milan will review it on Monday or so and if it's OK, I'll commit it early next week. I have already reworked it for the WebKit port, but the result was not good. There was only one class (EMFormat*) which was doing two completely separate actions - parsing and formatting and everything was stuffed in just a few .c files, making the code quite a mess. I have realized that the formatter could be made much more flexible and nicer by making proper object-oriented design. With Milan we have came up with quite a nice design. The first big step is to move everything to libemformat. Why have something here and something there. The parser and formatter were separated to their own classes EMailParser and EMailFormatter and the _actual_ parsing/formatting is done by extensions. Essentially there is a class for each mime type we support and they are derived from EExtension. This splitting makes the code much easier to read, navigate in and keep it in shape. As part of the work, I converted some plugins, namely audio-inline, itip- formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. There is no API yet to extend the preferences dialog though, so for this some of them still install a little EPlugin-based library with the GUI. The main improvement here is that they react to changes in settings immediately, no need to restart Evo, some of them even cause the current view to refresh immediately. When a proper API for this is in place we can make on-demand loading etc. And why we have done this all? Because of text-highlight module. I've written less technical blog about it, so see for yourself what we already have and what I plan for near future. http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ Bye Dan dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Retiring evolution-exchange
On Fri, 2012-06-01 at 06:57 -0400, Matthew Barnes wrote: On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: Then why not retire evolution-mapi instead of evolution-exchange ? I hadn't considered that. I'll defer to Milan to make that call. I thought evolution-mapi worked with Exchange 2003 servers at least in theory; I don't know how much actual testing that's had. And I know Milan has been maintaining evo-mapi more actively than evo-exchange and has a good working relationship with the OpenChange developers. In any case, maintaining this many different backends for Exchange is ridiculous and we need to drop at least one of them given our manpower shortage. I guess I don't care so much which, and am probably not the most qualified to choose. What do you think, Milan? Hi, the evolution-exchange doesn't have any active maintainer these days/months/years, the focus was moved to evolution-mapi during last few years, and recently to evolution-ews, as you know. I maintain evolution-mapi currently, and I will, at least until evolution-ews is more feature-rich. Another reason is that I spent quite some time on improvements in evolution-mapi for 3.4.0, making it more feature complete (with compare to evolution-exchange), and I basically rewrote its core. It's still about to make sure the changes work on each setup, but that's what the maintenance is about, isn't it. :) evolution-ews is far from evolution-mapi features, but it's still significantly quicker than evolution-mapi. I believe the biggest disadvantage on evolution-mapi is its slowness (on a lower layer, mostly with RPC calls). evolution-activesync sounds nice, though it does only mail currently, and I was told there are more limitations on the server side for it too, thus even I liked it as such, it is not usable for enterprise currently (feel free to correct me, David). There are more aspects how to compare these connectors, I wasn't asked to do that all here, but let's sum a bit with Chen's comment: evolution-exchange - for 2003 server only (through OWA/DAV) - basically no active maintenance evolution-mapi - for 2003,2007,2010 servers (through RPC/MAPI over TCP (no Outlook-anywhere/RPC-over-HTTP allowed (yet) - it currently waits on samba implementation of it)) - I maintain it - I guess semi-actively, planned to move to evolution-ews 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) evolution-activesync - basically for any server (not only exchange?) which supports ActiveSync protocol - like GMail, exchange 2007,2010 - currently very fresh, supports only mails 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. Do I make sense? I hope I do :) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit port of the composer
On Friday 01 of June 2012 11:47:31 Matthew Barnes wrote: On Fri, 2012-06-01 at 16:49 +0200, Daniel Vratil wrote: I have nearly finished reworking the e-mail formatter (details in the other mail) and I want to slowly turn my attention to the composer. It will be a lot of work, but hopefully I'll make it for 3.6 (no, I WILL make it for 3.6!!!). Awesome that you're starting in on that already! Next week or two will be mostly about fixing the bugs that I've postponed until the new formatter is landed. But I want to start shaping the composer in my head already :) 3.6 is pretty ambitious though. We can't be landing major features too late in the development cycle and 3.6 is already a doozy. You need to allow adequate time for testing and bug fixing before a stable release. 3.7.1 seems a more realistic target. I'd be no less thrilled to be rid of GtkHtml by 3.8. I wanted to aviod shipping a hybrid. But if you say so... If you have any special wish (I bet Andre will come with many feature requests from bugzilla :P ) you'd like to have in the new composer, please share them now. Regarding features, I want to make exact copy of GtkHTMLEditor and only fix the most annoying GtkHTML issues, all crazy ideas will be deferred for 3.8 :) Sounds pretty reasonable. My only request off the top of my head is to not subclass GtkWindow for your simple/html editors like GtkhtmlEditor does. That was never my intention :) That was a mistake on my part because it precludes us from embedding the editor in an existing window, and you'll likely want to do that later when you start working on a Conversation View. ;) I probably missed something...? :) I suggest GtkGrid as a base class. Yup :) Out of curiosity, what does WebKit/GTK+ use for spell checking? Enchant? Will their APIs allow us to recreate the context menu with spelling suggestions plus other editing actions? Yes, they use Enchant. The API [0] seem to be able to return only single word for autocorrect, but I guess we can fill in the missing functionality by working directly with Enchant? Dan [0] http://webkitgtk.org/reference/webkitgtk/stable/WebKitSpellChecker.html Matthew Barnes -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Retiring evolution-exchange
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A better mail formatter
On Fri, 2012-06-01 at 19:10 +0200, Dan Vratil wrote: I have realized that the formatter could be made much more flexible and nicer by making proper object-oriented design. With Milan we have came up with quite a nice design. That sounds freaking awesome! The first big step is to move everything to libemformat. Why have something here and something there. I vaguely recall EMFormatHTML had some mail-specific dependency that kept it in the mail library, but maybe that's long since been solved. It totally makes sense to consolidate if that's indeed possible now. The parser and formatter were separated to their own classes EMailParser and EMailFormatter and the _actual_ parsing/formatting is done by extensions. Essentially there is a class for each mime type we support and they are derived from EExtension. I'm literally crossing an item off my own To-Do list now. Nice! As part of the work, I converted some plugins, namely audio-inline, itip- formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. There is no API yet to extend the preferences dialog though, so for this some of them still install a little EPlugin-based library with the GUI. That would be itip-formatter and prefer-plain, right? Nowadays I'm not sure the Preferences dialog should even be extensible at all. It's too tempting to just tack on options willy-nilly without giving them sufficient thought. If something's important enough to show up in the application preferences then it probably ought to live in the core application. That's just my opinion. I'm inclined to suggest just add those plugin preferences directly. BTW, my branch and your branch will probably collide in itip-formatter, but hopefully the conflicts are easy to resolve. And why we have done this all? Because of text-highlight module. I've written less technical blog about it, so see for yourself what we already have and what I plan for near future. http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ Neat! Does the text-highlight have to be chosen each time or is it remembered somehow? Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit port of the composer
On Fri, 2012-06-01 at 16:49 +0200, Daniel Vratil wrote: If you have any special wish (I bet Andre will come with many feature requests from bugzilla :P ) you'd like to have in the new composer, please share them now. Regarding features, I want to make exact copy of GtkHTMLEditor and only fix the most annoying GtkHTML issues, all crazy ideas will be deferred for 3.8 :) Fixing some of the brokenness of the To/Cc/Bcc headers in the composer would be wonderful. Try this in the current composer: 1. Paste or enter this address into the To: header, exactly as follows: Woodhouse, David david.woodho...@intel.com 2. Click somewhere *outside* the To: header entry box. 3. Realise that the name is stupidly backwards and contains a stupid comma that shouldn't be in an RFC5322 display-name. (Yay Exchange) 4. Go back to the To: header entry, and put quotes around the display-name so it looks like Woodhouse, David david.woodho...@intel.com 5. Click somewhere outside the entry, again. 6. Watch the address magically transform itself to nonsense: Woodhouse, David david.woodho...@intel.com, David david.woodho...@intel.com In the past when our message *display* also gratuitously screwed with display-names to *remove* the quotes which were necessary to make them correct, this used to happen quite a lot when addresses were cut and pasted. We should also be able to send a mail with the following headers: To: Some people I want to invite to my party : ; Bcc: f...@bar.com Currently I get an SMTP error when I try that, because it treats the group in the To: header as a single address, and submits it in RCPT TO:Some people... party : ; -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
