Developers of Sympa

[Fil <address@concealed>]

** Serge:
> integration of Sympa and Spip.
> -2-modify SPIP in order to propose inside SPIP menu
>    subscribtion to Sympa lists.

I understand that this would be the best route.

> -3-review sympa MLM inside SPIP aadmin menu

Thinking about it, this is not necessary. The list-owner should
review the list from the MLM pane. It does not make sense otherwise.

> Fil conclusion is a invitation for a thread about this in both
> address@concealed and address@concealed.

I would suggest to use address@concealed only, as spip-dev iis in French.

> Most of those features could be very easy to introduce into Sympa.
> If SPIP include a SQL server that allow access to user emails,
> the first point is allready possible without modification of Sympa
> code.

Yes, that's true. One could hack spip to offer this "ML subscription bit"
and then have sympa search inside its database. But I think it's a bad idea:
what if the internals of spip change? Sympa will have to relearn it... We
need an excahge API.

** Olivier:
> Sympa's SOAP server includes all Sympa libraries so it does not have to
> redefine configuration loading, commands behavior, authentication,...
> It is written in Perl using SOAP::Lite module. Because it was initially 
> written to interface Sympa with an e-vote program (mod_survey), currently 
> it only implements a subset of Sympa's functions : 
>       * isSubscriber() : tells if a user is subscribed to a list
>       * amI() : tells if a user is owner of a list
>       * review() : review a list's subscribers

I suppose, for a start, that we could try to use isSubscriber() from inside
spip : if a user goes to his private options pane in spip, he could then
see, foreach sympa list spip knows about, if he is/not subscriber, with a
link to the wwwsympa web interface for subscription.

> But more will be integrated soon (subscribe(), unsubscribe(), which(),
> set_option(), get_arc(),...)

The second phase would be to use subscribe() and unsubscribe() - with a link
to wwwsympa if he wants "more".

I'll try and see what's already possible. Could you privately send me access
codes to a as-fully-as-possible-SOAPed sympa test list ?

                                * * *

One thought about the authentification: spip does not keep copies of its
users' passwords (it only tracks a moving-target MD5(challenge,password)),
so it cannot use them to authenticate into sympa.

If the implementation is correct and you trust spip, it would maybe be
possible to give a list-admin password (or cookie) to the spip database for
isSubscriber(), subscribe() and unsubscribe() methods..

But the spip user will not know what his sympa-password is, and thus will
not be able to go to the wwwsympa to set his options. In any case, if sympa
has a button "send me my password", I think we can live with that.

                                * * *

About the API:
I think it's rather clumsy to have to query sympa from within spip ; we risk
timeouts, inconsistencies and duplication of user db. I'd rather have it the
other way around: let sympa query spip to fetch a list of users to include.
Then we only have to give sympa a special password to do its request through
a web service (As I said a bit up, I'd rather not have it access the spip
DB -- if only for privacy reasons).
I've checked XMLRPC last night, it seems good for this kind of things ; I'll
check SOAP today.

What would you think?

In any case, the transfer mechanism between sympa and spip can be set nearly
independently from the datase and interface modifs in spip: I will start
by working on these aspects as we discuss APIs.


// PS for Antoine: si tu veux suivre la discussion, inscris-toi à sympa-dev

-- Fil