Developers of Sympa

[Antoine <address@concealed>]

Hi,

So there are two approches :

- polling : Sympa periodically tries to update its subscription
list from SPIP.

- pushing : SPIP automatically notifies Sympa when a user changes
his subscription preferences.

The "pushing" approach seems the most natural to me. It can be
made independant from SPIP ; and, if Sympa manages to agree with
other list management systems, it can be independent from Sympa
too (or at least compatible with other open-minded projects -
Mailman maybe ?). Also, it avoids inconsistencies coming from
the polling intervals (often users get on their nerves when
the "(un)subscribe" button does not seem to work like it should :-)).

The "push" approach would also be easier on a pure SPIP point of
view, because we have to generate our own SOAP requests, not parse
another client's requests. This is easier because we don't have
to allow and be able to parse every valid SOAP construct ; and SOAP
is a complicated language, especially if you want to do without
PHP's optional XML extensions and do the XML parsing by hand
(which we currently do for other stuff as well, e.g. database
snapshot recovery).

For a simple (crude ?) version of this, I don't see any problems
with authentication. When it receives a request for (un)subscribing,
Sympa (or Mailman, etc.) could just send the regular confirmation
e-mail like for any other request. That depends on what you expect
from such an interface, of course ;)

Yours

Antoine.


PS : an alternative to SOAP is XML-RPC. It is simpler, so easier to
parse and generate. There is also an experimental XML-RPC extension
for PHP (but as explained above we wouldn't use it for SPIP anyway).
It would surely make a difference if SPIP had to act as a server.
If SPIP is only a client, then SOAP vs. XML-RPC doesn't matter very
much, I think.

PPS : sorry, tried to subscribe to the list but either my SMTP or
IMAP server is slow, or so is your ML server. I'll try again later ;)