Stephanie da Silva wrote:
> Because of the dozens of different varieties of mailing list managers,
> I have my doubts that this will even work. But my question to you
> is, what would you think of a third party forwarding administrative
> requests to you/your listserver via their web interface?
Maybe I'm old-fashioned, but I don't think getting on a mailing list
should be _too_ easy.
I've got a web archive with a 'how to subscribe' button on it, that gets
you the subscripion help file. Even with all the hours I've spent trying
to write readable instructions, I still get totally clueless folks who
can't figure out that they need to use the -request address, even though
it is specifically mentioned several times.
I suspect that a reasonably competent programmer could write a parser
for PAML in its current form that produces a web subscription form,
though personally I would never attempt such a task.
Stephanie, it's YOUR list, and I trust you to do what is right with it,
both for the lists on it and for the net community.
I do suggest, however, that if you do license out your list in this fashion,
(and make SURE you get something in writing--among other things if this
'service' is charging money, you deserve a cut), you should make list managers
aware of that, and/or give them the option to have their list excluded
from the form. I doubt I would take such a step, or request my lists be
dropped from PAML entirely, but others might.
Changing the subject somewhat, I'm probably going to be switching list
engines by spring, either by writing my own or hacking an existing package.
Specifically, what I'm looking for is something that will allow folks to
move between various list formats, e.g., regular, digest, news-only, and
keyword based selection (only the posts that deal with those keywords--parsing
posts to determine keywords is a somewhat different issue), allow subscribers
to maintain their own list of posting addresses (home/work), go on vacation,
etc. I don't know that any one package currently does everything I want,
nor am I sure how the final product would fit into PAML.
If I thought 100% of my target audience had web browsers, I'd probably just
have a web-based subscription form with a bunch of radio buttons, but I
think that 5-10% of them are webless or stuck behind e-mail only firewalls.
Because I don't want to re-invent the wheel, especially things like
bounce processing, I'm leaning towards an extension to an existing package
as opposed to writing one from the ground up.