[elpa] Excorporate: Exchange integration package

[elpa] Excorporate: Exchange integration package

[Thomas Fitzsimmons]

Hi,

I wrote a library called Excorporate that allows Emacs to talk to an
Exchange server over the Exchange Web Services API.  I would like to
release it as a GNU ELPA package.  In the meantime, you can try it out
like this:

Download:
http://melpa.org/packages/calfw-20150206.1648.tar
http://www.fitzsim.org/emacs/excorporate-0.5.4.tar

M-x package-install-file calfw-20150206.1648.tar
M-x package-initialize
M-x package-install-file excorporate-0.5.4.tar

M-x excorporate
Follow prompts and enter Exchange credentials twice.

M-x calendar
Press 'e' to show today's meetings.

Alexandru Harsanyi provided lots of guidance and help extending
soap-client.el to support the full Exchange Web Services API.

Features
========

The core library has the following features:

- Fully asynchronous -- it never blocks redisplay except for one rare
  error recovery condition

- General API for making Exchange Web Services calls -- the entire EWS
  API is supported (i.e., the entire WSDL file is properly parsed by
  soap-client)

- Pure Emacs Lisp, using the built-in url and soap-client packages

- Support for all Emacs versions that support packages -- tested on
  versions 24.1 through 24.4 on GNU/Linux and MS-Windows

- Autodiscovery of configuration starting from only an email address

- NTLMv2 authentication

Proof of Concept
================

I've included a proof of concept that fetches today's meetings upon
request, and displays them using a calfw component.  I use this daily
and find it very convenient.  There's no support for week, two week or
month views since there's no caching.  Only read-only operations are
supported (e.g., you can't create meetings or respond to meeting
requests yet).

Mainly this release is to confirm all the tricky plumbing works for
people: autodiscovery, authentication, WSDL parsing.  Possible future
extensions include Gnus, Diary, EUDC and Org integration.

API
===

The API is simple for now.  The hard part of using it is figuring out
which Exchange Web Services operations to invoke, and their arguments.

(exco-api-version)
(exco-connect IDENTIFIER)
(exco-operate IDENTIFIER NAME ARGUMENTS CALLBACK)
(exco-disconnect IDENTIFIER)
(exco-extract-value PATH RESULT)
(exco-extend-timezone DATE-TIME-STRING)
(exco-format-date-time TIME-INTERNAL)

GNU ELPA Release Prerequisites
==============================

If the package is OK to go into GNU ELPA I'll need someone to confirm
copyright assignment for the following bundled dependencies:

url-http-ntlm.el (core library dependency):
Tom Schutzer-Weissmann <tom@schutzer-weissmann.net>

Tom may not have paperwork on file; need confirmation.  I can rewrite
this if necessary.  I want to generalize it a little anyway.

fsm.el (core library dependency):
Magnus Henoch <mange@freemail.hu>

Seems to have paperwork done, need confirmation.  fsm.el should probably
be its own ELPA package or bundled in Emacs.

emacs-calfw (proof-of-concept dependency, could be split out):
SAKURAI Masashi <m.sakurai at kiwanami.net>

Seems to have paperwork done, need confirmation.  calfw should probably
be its own ELPA package.

Bugs
====

- I bundled a patch to url-http-parse-headers to clear Authorization
  elements from url-http-extra-headers prior to executing a redirect,
  otherwise NTLM authentication doesn't work across redirects.  The
  implemented behaviour is backward compatible and should probably be
  committed to master (after review by a URL expert).

- On master only (24.1 through 24.4 are not affected) setting url-debug
  to 't causes url-retrieve to hang when contacting the server.  I'm not
  sure why yet.

Thomas

Re: [elpa] Excorporate: Exchange integration package

[Stefan Monnier]

> I wrote a library called Excorporate that allows Emacs to talk to an
> Exchange server over the Exchange Web Services API.  I would like to
> release it as a GNU ELPA package.  In the meantime, you can try it out
> like this:

I think I'm going to turn this one down, sorry.

We generally don't want packages that offer support for
proprietary programs.  It's OK for packages to support proprietary
programs "as a side-effect" of supporting something else, but packages
that only support proprietary programs are usually undesirable since
they end up promoting those proprietary programs, which is counter to
the goals of Free Software.

There can be exceptions (typically support for using Emacs on Windows
and Mac OS X platforms), when we consider that such support will
encourage people to rely on Free Software (e.g. Emacs) more than
it will encourage them to rely on proprietary programs.

In this case, I think this argument doesn't work, since you can already
use Emacs to access an Exchange server via IMAP (tho that admittedly
only covers some part of the functionality;and I don't know if other
parts can be similarly accessed via other standard protocols or not).


        Stefan

Re: [elpa] Excorporate: Exchange integration package

[Achim Gratz]

Stefan Monnier writes:
> We generally don't want packages that offer support for
> proprietary programs.  It's OK for packages to support proprietary
> programs "as a side-effect" of supporting something else, but packages
> that only support proprietary programs are usually undesirable since
> they end up promoting those proprietary programs, which is counter to
> the goals of Free Software.
>
> There can be exceptions (typically support for using Emacs on Windows
> and Mac OS X platforms), when we consider that such support will
> encourage people to rely on Free Software (e.g. Emacs) more than
> it will encourage them to rely on proprietary programs.
>
> In this case, I think this argument doesn't work, since you can already
> use Emacs to access an Exchange server via IMAP (tho that admittedly
> only covers some part of the functionality;and I don't know if other
> parts can be similarly accessed via other standard protocols or not).

In this case (speaking for me anyway), it would promote the use of Emacs
over Outlook.  The choice of mail server is not mine, but if an
alternative MUA supports all necessary functions and I don't bother
support with any problems, then I can use something else (at least at
the moment).


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [elpa] Excorporate: Exchange integration package

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There can be exceptions (typically support for using Emacs on Windows
> and Mac OS X platforms), when we consider that such support will
> encourage people to rely on Free Software (e.g. Emacs) more than
> it will encourage them to rely on proprietary programs.

The choice of the server is not yours, if you are working for a
company. I'm also confronted with an Exchange server @work.

> In this case, I think this argument doesn't work, since you can already
> use Emacs to access an Exchange server via IMAP (tho that admittedly
> only covers some part of the functionality;and I don't know if other
> parts can be similarly accessed via other standard protocols or not).

Thomas has started with Calendar integration. AFAIK, you need EWS in
order to access it on an Exchange server.

And even IMAP access is not always possible. IMAP access information for
that server was hidden in my company, and it took me a while to find it
out. Other people might fail to get IMAP access for an Exchange server,
depending on a company's policy.

>         Stefan

Best regards, Michael.

Re: [elpa] Excorporate: Exchange integration package

[joakim]

Michael Albinus <michael.albinus@gmx.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> There can be exceptions (typically support for using Emacs on Windows
>> and Mac OS X platforms), when we consider that such support will
>> encourage people to rely on Free Software (e.g. Emacs) more than
>> it will encourage them to rely on proprietary programs.
>
> The choice of the server is not yours, if you are working for a
> company. I'm also confronted with an Exchange server @work.
>
>> In this case, I think this argument doesn't work, since you can already
>> use Emacs to access an Exchange server via IMAP (tho that admittedly
>> only covers some part of the functionality;and I don't know if other
>> parts can be similarly accessed via other standard protocols or not).
>
> Thomas has started with Calendar integration. AFAIK, you need EWS in
> order to access it on an Exchange server.
>
> And even IMAP access is not always possible. IMAP access information for
> that server was hidden in my company, and it took me a while to find it
> out. Other people might fail to get IMAP access for an Exchange server,
> depending on a company's policy.

This is my case @work. I cant even get any form of sane access to the
exchange server. In my case the emacs exchange integration wouldnt work
either, but if it would, it would be a great help.



>
>>         Stefan
>
> Best regards, Michael.
>

-- 
Joakim Verona

Re: [elpa] Excorporate: Exchange integration package

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

On 02/08/2015 08:08 PM, Stefan Monnier wrote:
>> I wrote a library called Excorporate that allows Emacs to talk to an
>> Exchange server over the Exchange Web Services API.  I would like to
>> release it as a GNU ELPA package.  In the meantime, you can try it out
>> like this:
> 
> I think I'm going to turn this one down, sorry.
> 
> We generally don't want packages that offer support for
> proprietary programs. 

EWS is a commonly used network protocol and making sure that Emacs
cannot understand it helps nobody. If you want to drive the adoption of
free software, the first step is to make people want to use it.

> It's OK for packages to support proprietary
> programs "as a side-effect" of supporting something else, but packages
> that only support proprietary programs are usually undesirable since
> they end up promoting those proprietary programs, which is counter to
> the goals of Free Software.

Emacs does not have the usage numbers to meaningfully affect the
adoption of non-free software. Not once in my entire career has someone
said, "let's not use this technology: Emacs doesn't support it".

Maybe if Emacs had a few orders of magnitude more users, the strategy of
driving adoption by decreasing utility might make sense. As it stands,
rejecting features just drives users away, either to external
repositories or to other systems. Emacs rejecting EWS will have all the
broad social impact of the Amish rejecting automobiles.

> There can be exceptions (typically support for using Emacs on Windows
> and Mac OS X platforms), when we consider that such support will
> encourage people to rely on Free Software (e.g. Emacs) more than
> it will encourage them to rely on proprietary programs.
> 
> In this case, I think this argument doesn't work, since you can already
> use Emacs to access an Exchange server via IMAP (tho that admittedly
> only covers some part of the functionality;and I don't know if other
> parts can be similarly accessed via other standard protocols or not).

In addition to IMAP not supporting all use cases (like scheduling), some
Exchange administrators disable IMAP support completely.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [elpa] Excorporate: Exchange integration package

[Thomas Fitzsimmons]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I wrote a library called Excorporate that allows Emacs to talk to an
>> Exchange server over the Exchange Web Services API.  I would like to
>> release it as a GNU ELPA package.  In the meantime, you can try it out
>> like this:
>
> I think I'm going to turn this one down, sorry.
>
> We generally don't want packages that offer support for
> proprietary programs.  It's OK for packages to support proprietary
> programs "as a side-effect" of supporting something else, but packages
> that only support proprietary programs are usually undesirable since
> they end up promoting those proprietary programs, which is counter to
> the goals of Free Software.

OK, I'm definitely sympathetic to this view.  In this regard, my main
concern is that it's currently impossible for other Emacs developers to
test Excorporate using/against only Free Software.  One idea is if
OpenChange could grow EWS support in tandem with the features that
Excorporate actually uses, then there would be a Free Software option
for full Excorporate testing at all times (note: I'm not necessarily
signing up for this work).  Would that improve the appeal of Excorporate
for ELPA?

> There can be exceptions (typically support for using Emacs on Windows
> and Mac OS X platforms), when we consider that such support will
> encourage people to rely on Free Software (e.g. Emacs) more than
> it will encourage them to rely on proprietary programs.
>
> In this case, I think this argument doesn't work, since you can already
> use Emacs to access an Exchange server via IMAP (tho that admittedly
> only covers some part of the functionality;and I don't know if other
> parts can be similarly accessed via other standard protocols or not).

The counter-argument here is that Exchange Web Services is essentially
just providing a network service.  From following emacs-devel I was
under the impression that Free Software that talks to a network service
over a protocol was OK, regardless of what was implementing the protocol
on the other end.

Thomas

Re: [elpa] Excorporate: Exchange integration package

[David Kastrup]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I wrote a library called Excorporate that allows Emacs to talk to an
>>> Exchange server over the Exchange Web Services API.  I would like to
>>> release it as a GNU ELPA package.  In the meantime, you can try it out
>>> like this:
>>
>> I think I'm going to turn this one down, sorry.
>>
>> We generally don't want packages that offer support for
>> proprietary programs.  It's OK for packages to support proprietary
>> programs "as a side-effect" of supporting something else, but packages
>> that only support proprietary programs are usually undesirable since
>> they end up promoting those proprietary programs, which is counter to
>> the goals of Free Software.
>
> OK, I'm definitely sympathetic to this view.  In this regard, my main
> concern is that it's currently impossible for other Emacs developers
> to test Excorporate using/against only Free Software.  One idea is if
> OpenChange could grow EWS support in tandem with the features that
> Excorporate actually uses, then there would be a Free Software option
> for full Excorporate testing at all times (note: I'm not necessarily
> signing up for this work).  Would that improve the appeal of
> Excorporate for ELPA?

>> In this case, I think this argument doesn't work, since you can
>> already use Emacs to access an Exchange server via IMAP (tho that
>> admittedly only covers some part of the functionality;and I don't
>> know if other parts can be similarly accessed via other standard
>> protocols or not).
>
> The counter-argument here is that Exchange Web Services is essentially
> just providing a network service.

As long as this network service does not obey open standards and is
subject to change under the whim of a corporate identity, it is not
helpful for free software to encourage this interface over more reliably
available free ones.

> From following emacs-devel I was under the impression that Free
> Software that talks to a network service over a protocol was OK,
> regardless of what was implementing the protocol on the other end.

But not regardless of who controls the details of the protocol under
which conditions.  Also not regardless of existing implementations of
such protocol.  If it's only supported by non-free software, there is
really not much of a point for GNU software to support it.  Even if
there is support via a reverse-engineering clone like Samba (no idea
whether this is the case), one needs to look very carefully whether this
makes enough strategic sense to stand behind.

Stuff like Samba is really very much an outskirt into proprietary
software.  Supporting all of its aspects may not always be strategically
sound.  Often we might rather support protocols not under the control of
single proprietary vendors.

-- 
David Kastrup

Re: [elpa] Excorporate: Exchange integration package

[Stefan Monnier]

> OK, I'm definitely sympathetic to this view.  In this regard, my main
> concern is that it's currently impossible for other Emacs developers to
> test Excorporate using/against only Free Software.  One idea is if
> OpenChange could grow EWS support in tandem with the features that
> Excorporate actually uses, then there would be a Free Software option
> for full Excorporate testing at all times (note: I'm not necessarily
> signing up for this work).  Would that improve the appeal of Excorporate
> for ELPA?

Yes, if Excorporate can be used with OpenChange, then that'd be fine.

> The counter-argument here is that Exchange Web Services is essentially
> just providing a network service.  From following emacs-devel I was
> under the impression that Free Software that talks to a network service
> over a protocol was OK, regardless of what was implementing the protocol
> on the other end.

Hmm... that's a very good point.  Let me sleep on it.


        Stefan

Re: [elpa] Excorporate: Exchange integration package

[Stefan Monnier]

>> The counter-argument here is that Exchange Web Services is essentially
>> just providing a network service.  From following emacs-devel I was
>> under the impression that Free Software that talks to a network service
>> over a protocol was OK, regardless of what was implementing the protocol
>> on the other end.
> Hmm... that's a very good point.  Let me sleep on it.

My dreams told me that it's OK.  So feel free to install it in elpa.git.


        Stefan

Re: [elpa] Excorporate: Exchange integration package

[Thomas Fitzsimmons]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> The counter-argument here is that Exchange Web Services is essentially
>>> just providing a network service.  From following emacs-devel I was
>>> under the impression that Free Software that talks to a network service
>>> over a protocol was OK, regardless of what was implementing the protocol
>>> on the other end.
>> Hmm... that's a very good point.  Let me sleep on it.
>
> My dreams told me that it's OK.  So feel free to install it in elpa.git.

OK, will do, pending answers to my copyright assignment questions.
Still outstanding are:

   Tom Schutzer-Weissmann <tom@schutzer-weissmann.net>
   Magnus Henoch <mange@freemail.hu>

Thanks,
Thomas

Re: [elpa] Excorporate: Exchange integration package

[Tassilo Horn]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

Hi Thomas,

>>>> The counter-argument here is that Exchange Web Services is essentially
>>>> just providing a network service.  From following emacs-devel I was
>>>> under the impression that Free Software that talks to a network service
>>>> over a protocol was OK, regardless of what was implementing the protocol
>>>> on the other end.
>>> Hmm... that's a very good point.  Let me sleep on it.
>>
>> My dreams told me that it's OK.  So feel free to install it in elpa.git.
>
> OK, will do, pending answers to my copyright assignment questions.
> Still outstanding are:
>
>    Tom Schutzer-Weissmann <tom@schutzer-weissmann.net>
>    Magnus Henoch <mange@freemail.hu>

Magnus already has a CA for past and future changes on file for
EMACS/GNUS, so I guess he should be fine.

Bye,
Tassilo

Re: [elpa] Excorporate: Exchange integration package

[David Kastrup]

Tassilo Horn <tsdh@gnu.org> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
> Hi Thomas,
>
>>>>> The counter-argument here is that Exchange Web Services is essentially
>>>>> just providing a network service.  From following emacs-devel I was
>>>>> under the impression that Free Software that talks to a network service
>>>>> over a protocol was OK, regardless of what was implementing the protocol
>>>>> on the other end.
>>>> Hmm... that's a very good point.  Let me sleep on it.
>>>
>>> My dreams told me that it's OK.  So feel free to install it in elpa.git.
>>
>> OK, will do, pending answers to my copyright assignment questions.
>> Still outstanding are:
>>
>>    Tom Schutzer-Weissmann <tom@schutzer-weissmann.net>
>>    Magnus Henoch <mange@freemail.hu>
>
> Magnus already has a CA for past and future changes on file for
> EMACS/GNUS, so I guess he should be fine.

That's a different subproject.  I doubt that assignments cover one
subproject when given for a different subproject.

-- 
David Kastrup

Re: [elpa] Excorporate: Exchange integration package

[Tassilo Horn]

David Kastrup <dak@gnu.org> writes:

>> Magnus already has a CA for past and future changes on file for
>> EMACS/GNUS, so I guess he should be fine.
>
> That's a different subproject.  I doubt that assignments cover one
> subproject when given for a different subproject.

Yes, you are correct.  I've thought EMACS/GNUS means "Emacs and Gnus",
not "Gnus which is also part of Emacs".

Bye,
Tassilo

Re: [elpa] Excorporate: Exchange integration package

[Dmitry Gutov]

On 02/11/2015 02:59 PM, Tassilo Horn wrote:
> Yes, you are correct.  I've thought EMACS/GNUS means "Emacs and Gnus",
> not "Gnus which is also part of Emacs".

Is the above the exact wording is his assignment?

When I send instructions to contributors for projects on GNU ELPA, I 
recommend assigning copyright for "Emacs", not for "xxx, which is also a 
part of Emacs". Those are perfectly usable for different subprojects, too.

Re: [elpa] Excorporate: Exchange integration package

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Is the above the exact wording is his assignment?
>
> When I send instructions to contributors for projects on GNU ELPA, I
> recommend assigning copyright for "Emacs", not for "xxx, which is also
> a part of Emacs". Those are perfectly usable for different
> subprojects, too.

There are 4 entries for Magnus in copyright.list. The oldest entry is
for EMACS/GNUS, two other entries are for EMACS, and one entry is for
W3. I believe there is no problem.

Best regards, Michael.

Re: [elpa] Excorporate: Exchange integration package

[Tassilo Horn]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> Yes, you are correct.  I've thought EMACS/GNUS means "Emacs and
>> Gnus", not "Gnus which is also part of Emacs".
>
> Is the above the exact wording is his assignment?

EMACS/GNUS is the exact wording in copyright.list on fencepost without
clear definitions what that actually means.  But from other entries you
can guess that notation means PROJECT/SUBPROJECT or PROJECT/FILE, and
the assignments then only cover the mentioned subproject.  For example,
there are also CAs for EMACS/CALC and EMACS/CEDET,
EMACS/EMACS_MANUAL,EMACS/ELISP_MANUAL, and EMACS/HASHCASH.EL.

> When I send instructions to contributors for projects on GNU ELPA, I
> recommend assigning copyright for "Emacs", not for "xxx, which is also
> a part of Emacs".  Those are perfectly usable for different
> subprojects, too.

Yes, but the CA I've seen first when looking for Magnus is only for Gnus
which would not work for contributions to Emacs which are not in Gnus.
But as Michael already mentioned, Magnus has also younger CA for Emacs.

Bye,
Tassilo

Re: [elpa] Excorporate: Exchange integration package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We generally don't want packages that offer support for
  > proprietary programs.

That is indeed our policy, but I think this case doesn't fall under
it.  This is not a matter of supporting a proprietary program.  Rather
it is a matter of talking remotely with a server.

See http://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html.

I don't think we need to reject this on principle.  It's just a practical
technical matter.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: [elpa] Excorporate: Exchange integration package

[Michael Albinus]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Hi,

Hi Thomas,

> Alexandru Harsanyi provided lots of guidance and help extending
> soap-client.el to support the full Exchange Web Services API.

Do you plan also to update soap-client.el in the Emacs 25 repo? Last
time I've tried it I failed, because your work was done in a branch on
emacs-soap-client.googlecode.com.

> Thomas

Best regards, Michael.

Re: [elpa] Excorporate: Exchange integration package

[Thomas Fitzsimmons]

Michael Albinus <michael.albinus@gmx.de> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> Hi,
>
> Hi Thomas,
>
>> Alexandru Harsanyi provided lots of guidance and help extending
>> soap-client.el to support the full Exchange Web Services API.
>
> Do you plan also to update soap-client.el in the Emacs 25 repo? Last
> time I've tried it I failed, because your work was done in a branch on
> emacs-soap-client.googlecode.com.

Yes, Alex and I plan to do that.  I was waiting to release Excorporate
so that I was sure EWS support was complete before doing the merge.

To be clear, making EWS work involved extending soap-client's for XML
Schema Definitions in general ways.  There is nothing EWS-specific in
that work; nothing that advantages EWS over other SOAP services.  The
resulting improvements found bugs in soap-client's support for other
services like Debbugs.  I feel very strongly that Excorporate's
rejection from GNU ELPA has no bearing on merging these general
soap-client improvements.

(As an aside: I believe that, once merged, the new soap-client will
provide the closest thing that Emacs has ever had to full XSD validation
support.  I've seen talk of implementing XSD over the years on
emacs-devel; someone motivated may want to take a look at factoring
"xsd.el" out of soap-client.el.)

Thomas

Re: [elpa] Excorporate: Exchange integration package

[Michael Albinus]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> To be clear, making EWS work involved extending soap-client's for XML
> Schema Definitions in general ways.  There is nothing EWS-specific in
> that work; nothing that advantages EWS over other SOAP services.  The
> resulting improvements found bugs in soap-client's support for other
> services like Debbugs.  I feel very strongly that Excorporate's
> rejection from GNU ELPA has no bearing on merging these general
> soap-client improvements.

I know that, and I'll await happily the improved soap-client.el in the
repo.

Do you know something outstanding which shall be fixed in debbugs.el?
There are some hacks in Debbugs.wsdl I had to apply due to restricted
soap-client.el support, IIRC.

> Thomas

Best regards, Michael.

Re: [elpa] Excorporate: Exchange integration package

[Thomas Fitzsimmons]

Michael Albinus <michael.albinus@gmx.de> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> To be clear, making EWS work involved extending soap-client's for XML
>> Schema Definitions in general ways.  There is nothing EWS-specific in
>> that work; nothing that advantages EWS over other SOAP services.  The
>> resulting improvements found bugs in soap-client's support for other
>> services like Debbugs.  I feel very strongly that Excorporate's
>> rejection from GNU ELPA has no bearing on merging these general
>> soap-client improvements.
>
> I know that, and I'll await happily the improved soap-client.el in the
> repo.
>
> Do you know something outstanding which shall be fixed in debbugs.el?
> There are some hacks in Debbugs.wsdl I had to apply due to restricted
> soap-client.el support, IIRC.

One in particular is that soap-client wasn't handling xsi:type overrides
like this:

    <found xsi:type="apachens:Map">
      <item>
        <key xsi:type="xsd:string">24.3.50</key>
        <value xsi:nil="true" />
      </item>
    </found>

I had to update our soap-client test case to expect the string "24.3.50"
instead of the symbol 24.3, in this case, now that the override is
working.

If you can provide the hacked and unhacked Debbugs.wsdl I can try them
out in the test suite.  We'll also need to retest "live" debbugs-gnu
carefully as part of the merge to check for regressions.

Thomas

Re: [elpa] Excorporate: Exchange integration package

[Michael Albinus]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> If you can provide the hacked and unhacked Debbugs.wsdl I can try them
> out in the test suite.  We'll also need to retest "live" debbugs-gnu
> carefully as part of the merge to check for regressions.

Well, there isn't such a thing like "unhacked Debbugs.wsdl". When I
started to write debbugs.el, I had also to write Debbugs.wsdl from
scratch, because it didn't exist. The BTS guys use Perl's SOAP::Lite
module, no need for a *.wsdl file therefore.

I will review Debbugs.wsdl in order to find out the hacks I had to apply.

> Thomas

Best regards, Michael.

SOAP, WSDL

[Ivan Shmakov]

>>>>> Michael Albinus <michael.albinus@gmx.de> writes:
>>>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

 >> If you can provide the hacked and unhacked Debbugs.wsdl I can try
 >> them out in the test suite.  We'll also need to retest "live"
 >> debbugs-gnu carefully as part of the merge to check for regressions.

 > Well, there isn't such a thing like "unhacked Debbugs.wsdl".  When I
 > started to write debbugs.el, I had also to write Debbugs.wsdl from
 > scratch, because it didn't exist.  The BTS guys use Perl's SOAP::Lite
 > module, no need for a *.wsdl file therefore.

	… Which brings this long unasked question of mine: why can’t we
	just have soap-lite.el, too?  And thus cease to bother about
	either Debbugs.wsdl, /or/ WSDL support in soap-client.el in
	general – in the cases the service at hand doesn’t happen to
	provide a ready to use WSDL file.

	(I’m not a SOAP expert, but I’ve got an impression that WSDL is
	an entirely separate layer used over “plain” SOAP.)

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: SOAP, WSDL

[Michael Albinus]

Ivan Shmakov <ivan@siamics.net> writes:

> 	… Which brings this long unasked question of mine: why can’t we
> 	just have soap-lite.el, too?  And thus cease to bother about
> 	either Debbugs.wsdl, /or/ WSDL support in soap-client.el in
> 	general – in the cases the service at hand doesn’t happen to
> 	provide a ready to use WSDL file.

Most of the SOAP services I know offer an WSDL file. soap-client.el
gives you full support for that.

For debbugs a soap-lite.el package would have helped me three years ago,
but this is old history.

> 	(I’m not a SOAP expert, but I’ve got an impression that WSDL is
> 	an entirely separate layer used over “plain” SOAP.)

Well, looking at very complex WSDL files I believe it helps to
understand and implement the API details. With the experience of
debbugs, I believe it would have been more simple to implement it with
an existing WSDL file. Debugging Debbugs::SOAP (the Perl module from the
BTS team) was not simple as I hoped.

Something like soap-lite (be it Perl or Lisp) is easy to use for the
guys offering a service, as it has been for the BTS team. They know what
is behind. If you are just a "consumer" of an API, WSDL is more useful
for understanding.

Best regards, Michael.

Re: SOAP, WSDL

[Ivan Shmakov]

>>>>> Michael Albinus <michael.albinus@gmx.de> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> … Which brings this long unasked question of mine: why can’t we just
 >> have soap-lite.el, too?  And thus cease to bother about either
 >> Debbugs.wsdl, /or/ WSDL support in soap-client.el in general – in
 >> the cases the service at hand doesn’t happen to provide a ready to
 >> use WSDL file.

 > Most of the SOAP services I know offer an WSDL file.

	My experience with SOAP is very limited, but I believe I’ve
	stumbled over one or two which do not.

[…]

 >> (I’m not a SOAP expert, but I’ve got an impression that WSDL is an
 >> entirely separate layer used over “plain” SOAP.)

 > Well, looking at very complex WSDL files I believe it helps to
 > understand and implement the API details.  With the experience of
 > debbugs, I believe it would have been more simple to implement it
 > with an existing WSDL file.  Debugging Debbugs::SOAP (the Perl module
 > from the BTS team) was not simple as I hoped.

 > Something like soap-lite (be it Perl or Lisp) is easy to use for the
 > guys offering a service, as it has been for the BTS team.  They know
 > what is behind.  If you are just a "consumer" of an API, WSDL is more
 > useful for understanding.

	JFTR, – I’m not arguing against the merits of having a
	machine-readable API description.  Still, soap-client.el
	effectively requires the /user/ to supply one if it wasn’t
	provided by the service itself, – and I don’t think that’s all
	that helpful.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: [elpa] Excorporate: Exchange integration package

[Stefan Monnier]

> services like Debbugs.  I feel very strongly that Excorporate's
> rejection from GNU ELPA has no bearing on merging these general
> soap-client improvements.

Indeed, the two isses are quite separate, and regardless of Excorporate
(in|ex)clusion the soap-client changes would be very welcome.


        Stefan

Re: [elpa] Excorporate: Exchange integration package

[SAKURAI Masashi]

Hi,

At Sun, 08 Feb 2015 16:21:41 -0500,
Thomas Fitzsimmons wrote:
> :
> emacs-calfw (proof-of-concept dependency, could be split out):
> SAKURAI Masashi <m.sakurai at kiwanami.net>
> 
> Seems to have paperwork done, need confirmation.  calfw should probably
> be its own ELPA package.

Yes. I had done the paperwork in 2011.
What should I do for adding calfw to ELPA?
I'm glad to know such comment for calfw.

--
SAKURAI, Masashi (family, given)
m.sakurai@kiwanami.net