The mailing list for listmasters using Sympa

[Olivier Salaun - CRU <address@concealed>]

Hi Michelle,

Michelle Murrain wrote:

> [...]
> First, one of the things that I want/need, which is slightly separate 
> from the integration issue, but a necessary part of the project, is an 
> interface which allows users to choose the lists they'd like to 
> subscribe to, in a simple, one page form.
>
> For example, organization (domain) x has 5 lists: announce, events, 
> discussion, foo_committee and bar_committee. They want an interface 
> which allows people to subscribe and unsubscribe from their 5 lists 
> via a set of check boxes (you've seen those interfaces).
>
> Has anyone written an interface like that? Is it possibly in process 
> for sympa development?

We are thinking about adding this feature, probably available from the 
list of lists or a search or the list of subscriptions on the web 
interface. If the user is logged in, he could subscribe/unsubscribe with 
a single click (many checkboxes + a button).

Once we've finished the current work on TT2 (*), we planto work on the 
web user interface. The multiple subscription could be part of this...

> I'm thinking of two different avenues to do this: 1) direct interface 
> with the database, or 2) Sending sympa the requests (either by email 
> or via web services), which does allow sympa to handle the request, 
> and do what might be appropriate (wait for approval, confirm etc.).

The 3rd avenue, and the one we recommend, is to use Sympa SOAP interface 
that has been introduced to allow external applications to request Sympa 
services. This method has the advantage of preserving Sympa data 
integrity because the external program does not access Sympa private 
data directly ; it uses the right API for this.

We are distributing a PHP sample program that acts as a SOAP client for 
Sympa :
http://demo.sympa.org/sampleClient.php

> Now to the fun part: integration
>
> The web database system I want to integrate with sympa does standard 
> database stuff providing password protected access to content, 
> database tables. It includes on-the-fly form generation, plus, now 
> (this is the important part) personalized email based on record data 
> and sets of selection criteria.
>
> Basically, what I'd like to do is use the sympa database as the base 
> repository of the data, and have Xina (the name of the system) read 
> information from the sympa data. Part of the challenge is that the 
> sympa database holds data for many domains - meaning there needs to be 
> a way to segregate data by domain.
>
> I have two ideas, and I'm realizing I'm liking one better, but here 
> goes - this does mean I have to add a column to the subscribers_table 
> with domain.
>
> 1) Write a script that runs nightly, and syncs a set of tables for 
> each domain that the Xina system can read (and write to). This has the 
> advantage of allowing data from the Xina system to make it into sympa. 
> The disadvantage is that its periodic, thus not really 'live' data.
>
> 2) Use views. Create a view that selects data from the sympa table by 
> domain, which then the Xina system can read. I like this one best, 
> because it is absolutely live data, and also it lets sympa do what it 
> does best, manage subscriptions.

I don't quite understand what "domain" means for you ?

--
Olivier Salaün
Comité Réseau des Universités
-------------------------------------------
Validation signature / Trusting  signature: --> http://igc.cru.fr/trust.html
-------------------------------------------

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature