On Jan 16, 2009, at 3:19 PM, Frans Gouverne wrote:

This only make sense to me when there is also the possibility to
have "list-specific" subscriber fields As a reseller, many of my
customers are giving trainings and workshops For each training they
do have a separate mailing list What my customers actually want is
to maintain all kind of information about their clients e g which
trainings they have followed, if they have already payed, if they
want to receive news letters etc Most of this info is only
applicable for a specific training, that is for a specific mailing
list So for the subscriber profile, it's a good idea to have shared
subscriber fields But for many other info, list-specific subscriber
fields (public and non-public) are needed as well That also implies
that on the subscribers profile interface, it should be possible for
a subscriber to edit these list-specific subscriber fields marked as
"public"

I think the idea of list-specific subscriber fields is a good one -
but! :) it isn't currently on the spec, only the addition of allowing
the subscriber themselves to edit their own information, once
subscribed As of 3 0, the subscriber fields are shared between all
lists, but the information may be different for each and every list
the subscriber may be subscribed to My guess is that since it's the
same subscriber, that information is going to probably be pretty much
the same as well

From a technical point of view, I guess you only need to add one
extra field to the subscriber field its record This extra field
represents the list name to which the subscriber field belongs If
nothing is filled in (or "All" or something like that) it is valid
for all lists But maybe it's not that simple??

Right now, none of that sort of information is saved - there's no meta- data for the subscriber fields - the fields map almost directly to
columns added to the, "dada_subscribers" SQL table Your idea may be a
good one, once there is a table, say that holds that sort of
information as it really does open up the possibilities for doing some
interesting things

By the way, will the object which represents a collection of
subscribers (basically, a mailing list) only point to subscriber's
profiles in this new setup? That is, not having a list of email
addresses anymore for each mailing list, but just containing a list
of ID's which refer to the corresponding subscriber's profiles?
Personally I would prefer it this way to avoid duplicate storage of
email addresses,

Most likely - and I'm still hashing all this out, the API itself is
going to be very similar - it has to, so I don't break everyone's
everything :) and the only real changes is that there will be a table
that will only hold the subscriber fields and another table (profile)
that holds other meta data about the subscriber Right now, that meta
data is just a password, so they may login, but in the future, I'm
thinking it could hold other subscriber preferences

Those two new tables will only have one entry per email address, as
the information will be shared for all lists That leaves the original
table, dada_subscribers, with holding the actual subscriptions of the
email address to the various lists Each list has sublists, so there
is a good chance the email address associated with the subscriber will
be listed more than once

Basically, the profile table will have a one-to-many relationship with
the, dada_subscribers table and a one-to-one relationship with the
subscriber fields table

but I guess this will not be backwards compatible with existing
maling lists so an import tool is needed then, or?

It's sort of inevitable that I'm going to have to make a 3 0 to 3 1
migration tool, even for this small change - it may be a fact of life
from now on Hopefully it can all done as transparently as possible