Great Circle Associates Majordomo-Workers
(September 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: So where's this specification?
From: Dave Wolfe <dwolfe @ risc . sps . mot . com>
Date: Thu, 5 Sep 1996 10:31:08 -0500 (CDT)
To: tibbs @ hpc . uh . edu (Jason L Tibbitts III)
Cc: majordomo-workers @ greatcircle . com (Majordomo developer's mailing list)
In-reply-to: <199609042054.PAA18450@sina.hpc.uh.edu> from "Jason L Tibbitts III" at Sep 4, 96 03:54:31 pm
Reply-to: Dave Wolfe <david_wolfe @ risc . sps . mot . com>

[ Jason L Tibbitts III writes: ]
> 
> >>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:
> 
> DW> I would really hate to see *any* work done on 2.0 without a detailed
> DW> roadmap of where it's going.
> 
> Chan wants to make 2.0 a gradual change, not a complete rewrite. I
> agree. My aim is to clean up the namespace, get rid of the disgusting
> proliferation of globals and to reorganize the code into the email
> interface and the core action routines.

Irrelevent to the question: Where are your gradual changes taking
Mj? What are the goals (i.e. requirements and specifications) for Mj
2.0? Rather than risk offending you and anyone else by (apparently)
pointless debate about continual hacking vs designing, I'll not pursue
this further other than to say that the lack of requirements and
specifications, developed in the public forum of Mj development, dooms
your efforts to be (more or less) unassisted by the rest of the Mj
community.

> DW> At one time there was a discussion on this list about basically
> DW> making Mj 2.0 more of a server for which the e-mail client was
> DW> standard, with at least a Web client envisioned.
> 
> If you encapsulate everything properly you end up with that
> flexibility. I see some of what you're saying, [...] you have to
> define the client-server protocol. I don't think that's the case; if
> you define the module interface and the code uses it, you move to a
> client/server scheme by making the module be the intermediary. [...]
> That way you get both interfaces. Of course we still have to have a
> protocol, but it isn't exposed to the clients.
>
> Or perhaps we're on completely different wavelengths here.

Yes, but not about Mj, just about how development is done. :-) I agree
with your ideas about a client/server Mj, but my point is they're
premature. Is client/server one of the goals? What are the means to that
goal? You've outlined some of them here, but I'd like to see the whole
plan formalized and reviewed.

I'd hoped that John and/or Brent would pipe up with what one of them had
posted here awhile back about plans for 2.0. I did receive a copy of
John's "specification" (Thanks, Jen), but it was dated March 1994 and
didn't even broach the client/server concept, although it did contain a
lot of ideas about custom user modules.

-- 
 Dave Wolfe    *Not a spokesman for Motorola*
 Motorola MMTG  6501 Wm. Cannon Dr. W. OE112  Austin  TX  78735-8598


Follow-Ups:
References:
Indexed By Date Previous: Interesting 1.94beta1 tidbits
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Next: Re: So where's this specification?
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Indexed By Thread Previous: Re: So where's this specification?
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Next: Re: So where's this specification?
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>

Google
 
Search Internet Search www.greatcircle.com