>>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:
DW> Irrelevent to the question: Where are your gradual changes taking Mj?
DW> What are the goals (i.e. requirements and specifications) for Mj 2.0?
Not wanting to argue semantics, I reluctantly point out that to me
specifications means exact documentation of interfaces and such.
Requirements and future directions are something altogether different.
It's just too early to start specifying things to that level of detail. If
you're talking about something else, then I apologize for going down this
road entirely.
DW> Rather than risk offending you and anyone else by (apparently)
DW> pointless debate about continual hacking vs designing, I'll not pursue
DW> this further other than to say that the lack of requirements and
DW> specifications, developed in the public forum of Mj development, dooms
DW> your efforts to be (more or less) unassisted by the rest of the Mj
DW> community.
I actually agree with you, subject to a lax definition of specifications.
It's not that I want to work on this alone, just that until you stepped in
nobody's mentioned actually helping out. Unfortunately you stated a
requirement for a roadmap before you would do anything, and I don't have a
roadmap to supply. Nor, unfortunately, am I a good cartographer. You will
also notice that Chan has been silent on this issue. I don't know what
that means.
Still, for the sake of goodwill and the hope that something comes of it, I
offer up a hastily-gathered list of goals to be included at the end of this
message. Hopefully this can be turned into something like what you're
looking for.
DW> I agree with your ideas about a client/server Mj, but my point is
DW> they're premature.
You mentioned specifying interfaces and protocols; this is again probably
the semantics question again. I was just pointing out that most, if not
all, of that can be postponed until later.
DW> I'd hoped that John and/or Brent would pipe up with what one of them
DW> had posted here awhile back about plans for 2.0.
I hope for the same. I don't think John is still here, and I know Brent is
busy beyond imagination.
DW> I did receive a copy of John's "specification" (Thanks, Jen), but it
DW> was dated March 1994 and didn't even broach the client/server concept,
DW> although it did contain a lot of ideas about custom user modules.
We (maybe even I) came up with the client/server concept more recently as
an answer to the performance problems you get when handling piles of
requests. It wouldn't have been in anything written that long ago.
Anyway, here are my goals for future development. Yes, this is incredibly
vague but some of these aren't my ideas so I haven't really developed them.
Finally note that while I know something of the plug-in module idea I don't
know many of the particulars and I really have no idea at the moment of how
it might be done.
Planned for 1.95:
Add in various small features that have been requested during 1.94
development but didn't make it in.
Tighten up bad address checking and enhance instructional and warning
messages given to list users.
Continue code cleanup. This phase basically boils down to cleaning out
dead code, reorienting things to make them more readable, moving variable
declarations to the top of the function, cleaning up variable names, etc.
Goals for 2.x (in no order):
Perl5 only.
Address list kept in database (x > 0).
Client/server model (x > 1).
Plug in modules (x > 2).
Break functions up into classes (this list is not inclusive):
Internal:
Address manipulation:
Comment/Name stripping.
Verification/validation.
Domain munging.
Address list manipulation:
Internal:
Database accessors.
Flat file accessors.
External:
Add/Delete an address.
Check to see whether or not an address exists.
Find matching addresses.
Returning the address list.
Configuration management.
List information management:
Return list info.
Return new user message.
etc.
Notification:
Inform owner of various operations.
(client/server communication happens here)
External (email):
Process a piece of email looking for requests.
Send info returned by the internal functions back to requestors.
External (cgi):
you get the picture.
External (command line).
External (telnet).
External (what else is there? touch tone?)
No globals. Pass refs to data structures around instead. Keep in mind
that some structures may my accessed simultaneously be various forked
copies of a server.
Build resend functionality into the server. Mails are accepted by a tiny,
possibly even C program that just contacts the server and sends the message
over a socket to be delivered. Since we may not have addresses in a flat
file, we'll have to talk SMTP ourselves. Incorporate some or all of TLB
functionality.
That's all I have time for at the moment.
- J<
Follow-Ups:
References:
|
|
