$Id: ROADMAP.txt,v 1.1 2001/12/07 06:07:07 fhorch Exp $

This road map explains what we're trying to do and how we think we can get 
there.

[Just copying from the mailing list, will clean this up later. KFH]

--

>Sounds like the goal is NOT to do just a quick and dirty hack, and NOT
>to fork Mailman, but to write code that will become a part of the
>Mailman distribution, possibly starting in Mailman 2.1.

Correct, it will be a clean implementation. Well, not in 2.1, but 2.2 and 
3.0 perhaps. It will take some time until we have enough code and 
abstraction layer created, before we can merge. So, please start designing 
and coding. The more we get done over Christmas, the better will be my 
meeting with Barry in January, at which date a first merge could occur.

--

Whatever is going to go into MM2.1 has got to happen soon.  My goal is
to release MM2.1 by the Python conference in February.  That isn't
much time, so I've got to get to beta this month [December 2001].  Once beta 
hits, we'll be in feature freeze.

--

I see my main goals reached if we have a Zope-based user repository that can
be used by both Zope and Mailman. Something like the ultimate membership
module. With MM2.1., this seems to be a reachable goal.

I deliberately don't say ZODB, because I think a really sane architecture
will separate the storage issues for members and lists (which seem to be the
main objects to be concerned of) form the actual API. So we can use LDAP,
RDBMS, or even plain text files as data sources, like the Zope acl_user
folders do.

The member objects (holding member data, member credentials (password etc.),
member preferences) should work like extenden user folders from Zope. The
remaining question is:

Are we going to store the list memberships with the members or with the
lists? (What are plans for Mailman 2/3?) Or will there be a linking table
(which would be the SQL way of doing it)? Or will we have an API that
exposes methods like list.getAllMembers() to MailMan and leave the
implementation issues to the list and member storage modules?

--

first I want to say we need to stop dreaming. We are at the very beginning 
and have to get something working first, before addressing further abstract 
issues. We have not even recognized the pattern, so how can we talk about 
abstraction. Once we have *an* implementation it will be easier.

At 08:59 AM 12/5/2001 +0100, Joachim Werner wrote:
>Are we going to store the list memberships with the members or with the
>lists? (What are plans for Mailman 2/3?)

I think that is easy. Always, Members are going to be in Mailing Lists. 
They might not be full members, but at least a representation of them with 
some additional data. Also, I do not want to require having a central 
repository.
Thinking about it, all this management stuff should be defined in a 
separate application or product. I did that before with another site and it 
works well.
For example If a user is added to a User Folder, he is automatically signed 
up for a mailing list. This has nothing to do with ZMailman, since it is 
logic that belongs to the User Folder.

>Or will there be a linking table (which would be the SQL way of doing it)?

You can think of it this way if you like. Linking + extra data.

>Or will we have an API that
>exposes methods like list.getAllMembers() to MailMan and leave the
>implementation issues to the list and member storage modules?

Nope, because these modules also contain logic.

***START IMPORTANT ***

To everyone:
At the moment we are far away from the full data storage abstraction. Also, 
I do not want to think about a comprehensive membership-user handling. We 
do not even have the screens or any of the basic data structures ported, 
not even to mention the archives. We have plenty of issues *now*. Use your 
time and brain power solving *current* problems, instead of putting hours 
and hours in writing E-mails on how the ideal version could look like (I 
could write an entire article on that). These hours could be used to 
generate code.

***END IMPORTANT ***


Please, everyone, lets get some alpha code first (by then it is January) 
and then Barry and I (and whoever may want to join) will get together and 
try to propose some more final abstract design (for Mailman 3.0).

--

Let me just add one other note.  A lot of the "dream" features have
been discussed quite in depth on the mailman-developers list.
E.g. we've talked about what the data structures for the user and the
list objects will be in MM3.0.  We've talked a lot about the data
model.  We've talked a lot about how we'd eventually like things to
be.

So before posting elaborate wish lists here, I encourage folks to go
mine the mailman-developers archive.

--

I would like for people to come 
up with a set of "modules" or sections and claim it. They are then 
responsible for this section and its proper functioning...

- GUI/Frontend
- Data Structures
- Archives (since it will be very different)
- Mailman Integration (Functionailty)
- Data Storage independency

BTW, several people can work on one section and one person can work on 
several sections...but we need them all covered...

--

As far as focusing development efforts, rather than limiting the scope...
IMHO ZMailman's future should be open to embrace enhancements to the system.
At least we can document the best-of capabilities for later efforts instead
of letting them get buried in the list.  Others may be excite more by the
new ideas and contribute time to accomplish them.  There are some very good
ideas to create ZMailman beyond a me-too system on Zope.

Zope 10x could be contributed to by this project if we are successful in
creating a product that compels Mailman users to switch to ZMailman for all
the "NEW" Zope benefits and enhancements AND becomes a selling point to pick
Zope as a web-dev solution.
[...put down pom-poms]

Hurrah has committed to supporting this project.  We will set-up zMailman
testing there with intentions they will offer Zmailman to all their Zope
customers(growing exposure.)

--

BTW, we are collaborating very closely with Barry Warsaw, so most of the 
work we are doing is fully accepted and we will be part of the ZMailman 3.0 
design. Right now I am focusing on wrapping the existing API and make it 
available in Zope, since I noticed that implementing the entire data 
structure tree from scratch would be a lot of work (probably wasted), since 
Mailman 3.0 will be in anyway designed with Zope 3.0 in mind.... but if we 
get the Web-frontend going and write maybe a couple cool products, like a 
Mailman User Folder, then we will definitely have reached our goal.

--

