Comments on: Toward mailnews Exchange Web Services support: SOAP calls http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/ Messaging with Mozilla by rkent Sun, 18 Jul 2010 18:30:57 +0000 hourly 1 http://wordpress.org/?v=3.0 By: MesQuilla » Blog Archive » Mailnews Exchange Support: the Ews Native layer http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-117 MesQuilla » Blog Archive » Mailnews Exchange Support: the Ews Native layer Tue, 16 Mar 2010 19:38:22 +0000 http://mesquilla.com/?p=593#comment-117 [...] integration project needed another layer in the architecture. Previously, I have discussed a layer that does SOAP calls, and a second layer that extends Mozilla mailnews objects. (Let me call the Mozilla-specific world [...] [...] integration project needed another layer in the architecture. Previously, I have discussed a layer that does SOAP calls, and a second layer that extends Mozilla mailnews objects. (Let me call the Mozilla-specific world [...]

]]> By: MesQuilla » Blog Archive » Mailnews Exchange Support: basic mail infrastructure http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-112 MesQuilla » Blog Archive » Mailnews Exchange Support: basic mail infrastructure Wed, 03 Mar 2010 22:31:48 +0000 http://mesquilla.com/?p=593#comment-112 [...] my last report, I was testing and updating the old Mozilla SOAP framework for use in communicating with Exchange [...] [...] my last report, I was testing and updating the old Mozilla SOAP framework for use in communicating with Exchange [...]

]]> By: rkent http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-104 rkent Thu, 04 Feb 2010 17:26:29 +0000 http://mesquilla.com/?p=593#comment-104 Response to Leni: I'm in the process of trying to understand SOAP better myself, but from my current understanding I would characterize the EWS SOAP as RPC style. "you might be better off building special-purpose helper libraries on top of XMLHttpRequest" I am only using a fraction of the webservices extension, and currently plan to build special-purpose helper libraries on top of that. The portion of the webservices extension I am using translates to/from XML into an intermediate format, where information is organized into nsIPropertyBag objects (and I have added some nsIArray to the mix). I still have to have another layer that will translate that to/from the Mozilla mailnews formats. I guess what you are saying is that I can use XML tools like XPath to do some of those same operations. I'll have to give that a try as well before I get too committed to my current path. "the webservices extension has more than it’s fair share of edge-case bugs" and so do other SOAP libraries. For example, I read that the AXIS2 library does not work with Exchange Server Web Services. If I am going to fix bugs, I would rather do it in the Mozilla environment at this point in my experience. And I am committed to doing any fixes that I need to the webservices code. Response to Leni:

I’m in the process of trying to understand SOAP better myself, but from my current understanding I would characterize the EWS SOAP as RPC style.

“you might be better off building special-purpose helper libraries on top of XMLHttpRequest”

I am only using a fraction of the webservices extension, and currently plan to build special-purpose helper libraries on top of that. The portion of the webservices extension I am using translates to/from XML into an intermediate format, where information is organized into nsIPropertyBag objects (and I have added some nsIArray to the mix). I still have to have another layer that will translate that to/from the Mozilla mailnews formats. I guess what you are saying is that I can use XML tools like XPath to do some of those same operations. I’ll have to give that a try as well before I get too committed to my current path.

“the webservices extension has more than it’s fair share of edge-case bugs” and so do other SOAP libraries. For example, I read that the AXIS2 library does not work with Exchange Server Web Services. If I am going to fix bugs, I would rather do it in the Mozilla environment at this point in my experience. And I am committed to doing any fixes that I need to the webservices code.

]]> By: rkent http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-103 rkent Thu, 04 Feb 2010 17:10:40 +0000 http://mesquilla.com/?p=593#comment-103 (Leni wanted to post this, but he had troubles so sent by private email instead): When I first began using SOAP I didn't understand the difference between a document-oriented SOAP api and an RPC-style API. What I learned was that clients of a document-oriented API get marginal value from a SOAP library in exchange for complexity. Most of the work is in: * understanding the document structure and relationships * parsing and building documents If Exchange is going with a document-oriented API (like Zimbra did), you might be better off building special-purpose helper libraries on top of XMLHttpRequest. That's what zindus did when it switched away from the webservices extension in <a href="http://www.zindus.com/blog/2008/03/07/testing-release-2008-03-07-soapurl-and-mozilla-soap/" rel="nofollow">march 08</a> and it was definitely the right decision. Also, the webservices extension has more than it's fair share of edge-case bugs. (Leni wanted to post this, but he had troubles so sent by private email instead):

When I first began using SOAP I didn’t understand the difference between a document-oriented SOAP api and an RPC-style API.

What I learned was that clients of a document-oriented API get marginal value from a SOAP library in exchange for complexity. Most of the work is in:
* understanding the document structure and relationships
* parsing and building documents

If Exchange is going with a document-oriented API (like Zimbra did), you might be better off building special-purpose helper libraries on top of XMLHttpRequest. That’s what zindus did when it switched away from the webservices extension in march 08 and it was definitely the right decision.

Also, the webservices extension has more than it’s fair share of edge-case bugs.

]]> By: rkent http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-102 rkent Wed, 03 Feb 2010 17:50:46 +0000 http://mesquilla.com/?p=593#comment-102 openchange is the open-source option that has been suggested to me before. There are a variety of reasons why I am not looking at this initially. First, as I understand it the direction that Microsoft is moving is away from MAPI and towards EWS as "true exchange support". Their Outlook for Mac (Entourage), for example, as I understand it, never used MAPI, and is being rewritten to rely completely on EWS. As an new effort, I would rather code to the future rather than the past. Your posting implies that EWS is not real Exchange support, but I don't think that is correct for the future. Second, openchange does not list Windows as supported, while this is important to TB's user base. Third, openchange is under a GPL license. As I said in my posting, I'm not ready to commit myself to that path at this point in time. openchange is the open-source option that has been suggested to me before. There are a variety of reasons why I am not looking at this initially.

First, as I understand it the direction that Microsoft is moving is away from MAPI and towards EWS as “true exchange support”. Their Outlook for Mac (Entourage), for example, as I understand it, never used MAPI, and is being rewritten to rely completely on EWS. As an new effort, I would rather code to the future rather than the past. Your posting implies that EWS is not real Exchange support, but I don’t think that is correct for the future.

Second, openchange does not list Windows as supported, while this is important to TB’s user base.

Third, openchange is under a GPL license. As I said in my posting, I’m not ready to commit myself to that path at this point in time.

]]> By: James http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-101 James Wed, 03 Feb 2010 16:52:16 +0000 http://mesquilla.com/?p=593#comment-101 If you want true exchange support, why not use the http://www.openchange.org/ native MAPI support? If you want true exchange support, why not use the http://www.openchange.org/ native MAPI support?

]]> By: rkent http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-100 rkent Tue, 02 Feb 2010 15:22:33 +0000 http://mesquilla.com/?p=593#comment-100 I'd certainly like to support that in the future. "Next steps" though is trying to figure out what is the easiest possible thing that I could do which would exercise EWS Soap calls in a Gecko environment. I doubt if Public Folders are any easier than normal folders, plus I am less familiar with the Mozilla code that might support that, so my first reaction is that that does not make a good next step for me. I’d certainly like to support that in the future. “Next steps” though is trying to figure out what is the easiest possible thing that I could do which would exercise EWS Soap calls in a Gecko environment. I doubt if Public Folders are any easier than normal folders, plus I am less familiar with the Mozilla code that might support that, so my first reaction is that that does not make a good next step for me.

]]> By: moZes http://mesquilla.com/2010/02/01/toward-mailnews-exchange-web-services-support-soap-calls/comment-page-1/#comment-99 moZes Tue, 02 Feb 2010 10:36:18 +0000 http://mesquilla.com/?p=593#comment-99 Great work in progress! If I may make a suggestion: can you add to the next steps also the ability to access Public Folders (or Sharepoint)? Great work in progress!
If I may make a suggestion:
can you add to the next steps also the ability to access Public Folders (or Sharepoint)?

]]>