Implementing real names

Implementing real names

[Ben Schmidt]

Hi,

I'd like to test the water regarding this one.

A feature that I would find useful is having a membership list that includes real 
names. Likewise, it would be helpful having real names included in subscription 
and unsubscription notification emails (and subscription moderation emails) and 
possibly post moderation emails, too. This should initially come from the From: 
header of mail sent to +subscribe addresses, but should be able to be changed by 
the list owner as desired, also.

Particularly given our conservative maintainer :-) and that this could be a fair 
amount of work, and have some implementation subtleties, I think this is worth a 
bit of discussion before I dive in and try anything.

So, I'm wondering what people think of this, and how it might be implemented.

The information could be stored in subscribers.d, etc. files, but I think this is 
probably a bad idea, as all the code that uses those files would need to be 
changed to parse them.

Perhaps it would make sense to have a realnames.d? Files under that directory 
could contain email address and realname separated on a line by a tab. Searches 
similar to the search that's done for a subscriber-only list could then be done to 
look up the real name for any subscriber. The membership list could be constructed 
by carefully traversing both subscribers.d and realnames.d in step. Lookups of 
real names and the membership list could become a bit more expensive, but posting 
messages would be unaffected, and not so much code would need changing (and 
testing, etc.).

Another possibility would be to keep the data in some kind of simple database file 
that facilitated quick lookup and update. This seems a bit out-of-style with how 
mlmmj works, though.

Thoughs?

Ben.

Re: Implementing real names

[Devin Ceartas]

I like the idea. Not having read the code, the implementation sounds  
reasonable.

Devin Ceartas
Owner, NacreData L.L.C.

On Jan 26, 2010, at 7:47 AM, Ben Schmidt  
<mail_ben_schmidt@yahoo.com.au> wrote:

> Hi,
>
> I'd like to test the water regarding this one.
>
> A feature that I would find useful is having a membership list that  
> includes real names. Likewise, it would be helpful having real names  
> included in subscription and unsubscription notification emails (and  
> subscription moderation emails) and possibly post moderation emails,  
> too. This should initially come from the From: header of mail sent  
> to +subscribe addresses, but should be able to be changed by the  
> list owner as desired, also.
>
> Particularly given our conservative maintainer :-) and that this  
> could be a fair amount of work, and have some implementation  
> subtleties, I think this is worth a bit of discussion before I dive  
> in and try anything.
>
> So, I'm wondering what people think of this, and how it might be  
> implemented.
>
> The information could be stored in subscribers.d, etc. files, but I  
> think this is probably a bad idea, as all the code that uses those  
> files would need to be changed to parse them.
>
> Perhaps it would make sense to have a realnames.d? Files under that  
> directory could contain email address and realname separated on a  
> line by a tab. Searches similar to the search that's done for a  
> subscriber-only list could then be done to look up the real name for  
> any subscriber. The membership list could be constructed by  
> carefully traversing both subscribers.d and realnames.d in step.  
> Lookups of real names and the membership list could become a bit  
> more expensive, but posting messages would be unaffected, and not so  
> much code would need changing (and testing, etc.).
>
> Another possibility would be to keep the data in some kind of simple  
> database file that facilitated quick lookup and update. This seems a  
> bit out-of-style with how mlmmj works, though.
>
> Thoughs?
>
> Ben.
>
>
>
>
>

Re: Implementing real names

[Morten Shearman Kirkegaard]

Hi Ben,

On Tue, 2010-01-26 at 23:47 +1100, Ben Schmidt wrote:
> A feature that I would find useful is having a membership list that
> includes real names.

Is that ment as a convenience for the list administrator (when finding
and unsubscribing clueless users), or would it be useful in other
situations?

> Particularly given our conservative maintainer :-) and that this could
> be a fair amount of work, and have some implementation subtleties, I
> think this is worth a bit of discussion before I dive in and try
> anything.

:-)

> So, I'm wondering what people think of this, and how it might be
> implemented.
...
> Another possibility would be to keep the data in some kind of simple
> database file that facilitated quick lookup and update. This seems a
> bit out-of-style with how mlmmj works, though.

I have a long term vision...

Some users of mlmmj keep subscribers in a database. When sending mails
to mlmmj, the mail is not piped to mlmmj-recieve [sic] at first, but
into a fetch-the-subscriber-list-and-execute-mlmmj-recieve-script. This
works okay for newsletter lists, with web-based subscription, if you
ignore bounces. It is not good for discussion lists.

My idea is to restructure mlmmj with a set of hooks. The hooks could
just be executable files in a directory. There could be a hook for
subscribing, one for unsubscribing, one for getting the subscriber list,
one for adding the footer, and so on. The default hooks would do a large
part of what mlmmj does today.

This would allow mlmmj to be used with any storage backend.

If a database based backend was written, per-subscriber settings could
easily be saved. The real name of a subscriber would just be a setting,
much like I imagine "notmetoo" being.

What's your thoughts on this?


Morten

-- 
Morten Shearman Kirkegaard <moki@fabletech.com>
CTO, FableTech
http://fabletech.com/

Re: Implementing real names

[Ben Schmidt]

Hi, Morten,

Thanks a lot for working your way through all the January mail. I really
appreciate the comments and discussion and your openness to changes.

>> A feature that I would find useful is having a membership list that
>> includes real names.
>
> Is that meant as a convenience for the list administrator (when finding
> and unsubscribing clueless users), or would it be useful in other
> situations?

Yes, it's just an administration convenience to find emails, whether to
unsubscribe users, send them a personal message, find out which real
person is bouncing to nag them face-to-face about their incorrect
address, etc..

>> Another possibility would be to keep the data in some kind of simple
>> database file that facilitated quick lookup and update. This seems a
>> bit out-of-style with how mlmmj works, though.
>
> I have a long term vision...
>
> Some users of mlmmj keep subscribers in a database. When sending mails
> to mlmmj, the mail is not piped to mlmmj-recieve [sic]

LOL. Yes. That really should be a candidate, perhaps with changing the
access keyword from 'moderate' to 'hold', for fixing in the next major
release. Though it doesn't really matter, it projects an image of the
project that I don't think reflects the quality of the product. It may
even increase adoption, having it right.

Some tunable names could be adjusted to be more sensible and consistent,
too. And all this supplied with a nice 'upgrade' script for admins. :-)

> at first, but into a
> fetch-the-subscriber-list-and-execute-mlmmj-recieve-script. This works
> okay for newsletter lists, with web-based subscription, if you ignore
> bounces. It is not good for discussion lists.

I don't think I understand how this works at present. Does mlmmj-recieve
have an option to support this? I don't see anything.

> My idea is to restructure mlmmj with a set of hooks. The hooks could
> just be executable files in a directory. There could be a hook for
> subscribing, one for unsubscribing, one for getting the subscriber list,
> one for adding the footer, and so on. The default hooks would do a large
> part of what mlmmj does today.

I think having a bunch of hooks is a good idea. The content filtering
stuff would definitely be better as a hook, and probably should happen
at a different point in the processing chain, too.

> This would allow mlmmj to be used with any storage backend.
>
> If a database based backend was written, per-subscriber settings could
> easily be saved. The real name of a subscriber would just be a setting,
> much like I imagine "notmetoo" being.
>
> What's your thoughts on this?

There is definitely a lot of potential in something more flexible like
this. It raises a lot of issues, though:

- With per-user settings, and with an increasing number of these (and I
   do think that long term, they are a plus), having some kind of web
   interface becomes more of a necessity than an optional extra. Managing
   your settings via an email interface quickly becomes tedious, even for
   cluey users. Users who are less savvy haven't got a hope. Likewise for
   administrators, commandline tools quickly become difficult to use as
   they require more and more options. So admins can lessen their own
   burdens by shifting work to users, the interface could have a nice
   button (and possibly mail interface) to email specific users a HOWTO!

- Nomail and digest would probably also become per-subscriber options in
   this model, rather than discrete lists.

- Bounce handling would probably also need to be integrated with it,
   probably as further per-subscriber metadata.

- Also, subscribers who are moderated (or not) could be a very useful
   option to include. It would simplify greatly the implementation of
   moderating new members that I wrote about earlier, too.

- Who the admins and moderators are could also be made per-subscriber
   metadata. This would be more consistent than having some info in
   tunables, and some in the database. With a web interface, this would
   easily allow logging in to administer the list, too. Basically
   anything email-address related (except probably the list address)
   could move to the database.

- There are some other really nice things you could do with this, too,
   such as making archives available online to list members.

- How would efficiency suffer with needing to fork and execute more
   processes? How platform-specific would efficiency problems be? Maybe a
   C interface is smarter, so backends are modules. One such module could
   be the current mlmmj code (which may well be quite easy to move into a
   module with very little reworking--and could provide for a smooth
   transition to something new). Another could work by executing external
   programs. Others could be speedy interfaces to various databases. A
   CGI script could provide an mlmmj web interface that interfaces with
   the modules, too, enabling whatever functionality the backend in use
   provides.

- Long term, what should the default module/backend be? One of the
   beauties of mlmmj is its utter transparency. Files are all very
   readable at the commandline. It would be a shame to lose this.
   Much like Thunderbird does, perhaps the default module long-term could
   provide an index into flat files, rather than use an opaque database
   format. (Thunderbird stores mail in mbox files but creates indexes
   into those files for efficiency.)

- Likewise, one reason I favour mlmmj is its low memory use, and the way
   it doesn't need a daemon (or 5) running. I'd be keen for a default
   backend that is more featureful, but still has these niceties.

- We'd want to get CVS (or preferably something better--I favour
   Mercurial these days) publicly available, particularly so we could
   have a broader testing community if implementing something more
   ambitious like this.

That's enough thoughts from me for now. Your turn!

I'd definitely be willing to help with something like this, too. I was
pretty close to biting the bullet and writing my own MLM after
investigating a bunch of others with just weren't really suitable, and
mlmmj stepped in as pretty close to a decent solution. The code was nice
enough that I could easily implement the missing features I needed, at
least the high priority ones. That's plenty less work than writing an
entire MLM on my own, so I'm definitely willing to put in some time to
implementing some of these lower priority but useful features, too.

Ben.