<HTML>
<HEAD>
<!-- =================================================================== -->
<META HTTP-EQUIV="EXPIRES" CONTENT="Fri, 02 Feb 1996 11:04:53 PDT 1996">
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<META NAME="KEYWORDS" CONTENT="MajorCool, Majordomo, Web, CGI, mailing list">
<META NAME="DESCRIPTION" CONTENT="MajorCool is a Web interface to Majordomo. This is an installed copy; the definitive site for MajorCool info is http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/">
<!-- =================================================================== -->
<TITLE>MajorCool Future Direction</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<DIV ALIGN=CENTER>
<TABLE WIDTH=100% BORDER=0 ALIGN=CENTER VALIGN=TOP>
<TR>
<TD WIDTH=520 ALIGN=CENTER VALIGN=MIDDLE>
<DIV ALIGN=CENTER>
<IMG SRC="../icons/mc_cool_banner.gif" ALT="[MajorCool]" ALIGN=MIDDLE>
<H3 ALIGN=CENTER>MajorCool: A Web Interface To Majordomo</H3>
<FONT SIZE=-1><!--META-->(This is a copy of the <I>MajorCool</I> <A HREF="http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/">master</A> documentation set)</FONT>
</DIV>
</TD>
<TD ALIGN=RIGHT VALIGN=TOP>
<FONT SIZE=2>
<A HREF="index.htm">Introduction</A><BR>
<A HREF="usage.htm">Usage</A><BR>
<A HREF="prereq.htm">System Requirements</A><BR>
<A HREF="install.htm">Installation</A><BR>
<A HREF="config.htm">Configuration</A><BR>
<B>Future Direction</B><BR>
<A HREF="support.htm">Licensing, FAQs, & Credits</A><BR>
</FONT>
</TD>
</TR>
</TABLE>
</DIV>
<HR>
<A NAME="FUTURE">
<H2>Future Direction</H2>
</A>
<P><I>MajorCool</I> is by no means complete. There are plenty of things to
fix and/or improve. Alas, these will not be addressed in the 1.x series,
as focus has now shifted to supporting the future <I>Majordomo</I>
2.0 product.
<A NAME="CONCERNS">
<H3>Design Concerns</H3>
</A>
<UL>
<LI><B>Authentication</B> -- Using the Web to augment a mail-based
system is always problematic. Barring the use of <I>htpasswd</I> or
other server-based authentication, there is no way to trust that the
user is whom [s]he says [s]he is. For <I>MajorCool</I>, a decision was
made to "bite the bullet" and trust that the end-user can correctly
specify his/her e-mail address (or name). <CODE>$trust_identity</CODE>
was implemented to partially address the issue. However, this still
leaves the door open for tampering with list subscriptions under a
false name. In order to minimize this risk, the <I>httpd</I>
<B>REMOTE_HOST</B> and <B>REMOTE_ADDRESS</B> CGI variables are sent as
part of address comments in the simulated e-mail header. Thus,
<I>Majordomo</I> maintains an accurate Log of who submitted Web
requests. If authentication can be improved in any way, it can only
serve the users better.
<P>
<LI><B>Results Feedback</B> -- The single biggest limitation of the
chosen design is the fact that <I>Majordomo</I> still sends final
results of "change" actions via e-mail. Although <I>MajorCool</I> does
a majority of the front-end work interactively, the interpretation of
the <I>Majordomo</I> modify actions is not possible and the user must
instead watch for e-mail confirmation. An API interface to
<I>Majordomo</I> would be monumentally useful, allowing actions to be
performed with the results returned as a function call return rather
than assuming e-mail.
<P>
<LI><B>Performance</B> -- Because <I>Majordomo</I> is ultimately used
to perform any actual work for list or configuration changes, the
<I>MajorCool</I> app is at the mercy of how fast <I>Majordomo</I> can
process the submitted commands. Given this and the above Feedback
limitation, it may be more appropriate to simply hand off the tasks to
<I>Majordomo</I> as a background process and not have <I>MajorCool</I>
wait for command completion as it currently does. In other words, is
the 'trace' output really necessary?
</UL>
<A NAME="TODO">
<H3>Bugs/Misfeatures/ToDo</H3>
</A>
<UL>
<LI><B>Document returns no data.</B> Some users have reported that
BROWSE mode in 1.3.x is resulting in a "Document returns no data"
output. I am unable to reproduce this error; it is probably a Perl
run-time (as opposed to syntax) error. The fact that it is a null
document rather than a 500 HTTP response indicates that the HTTP
header is being transmitted before the script ends prematurely.
However, there has yet to be an error indicated in the Web server
logs. I suspect this is memory-related, but I cannot be sure. If
you are experiencing this behavior, any system info (Perl version,
Web server version, OS, memory, etc) you can provide might help to
identify common traits.
<P>
<LI><B>Word-wrap of the <CODE>info</CODE> file.</B> Despite the use
of <CODE>WRAP=PHYSICAL</CODE> and the Preferences setting to control
it, wrapping of the file is not working correctly.
<P>
<LI><B>Archive list & file <CODE>get</CODE> interface.</B> The next
logical step would be to provide access to <I>Majordomo</I> list archives,
possibly even augmented by HTML formatting via tools such as
<A HREF="http://www.eit.com/software/hypermail/">HyperMail</A> or
<A HREF="http://www.oac.uci.edu/indiv/ehood/mhonarc.html">MHonArc</A>.
<P>
<LI><B>Bypass the Key Cache.</B> The use of the key cache was
necessitated by the inherent slowness of the <CODE>get_config()</CODE>
API call when plodding through all lists that the server offers.
When/if <I>Majordomo</I> moves to a more efficient file interface, we
will be able to dump the caching, thus eliminating an extra
installation step.
<P>
<LI><B>More complete <CODE>is_advertised()</CODE> address matching.</B>
The <CODE>is_advertised()</CODE> function should probably match against
address patterns rather than primary address. But this would involve
comparing RE's to RE's, and I was too lazy to investigate how.
<P>
<LI><B>Cross-pollinate <CODE>siteaddr()</CODE> and <CODE>sort
by_siteaddr</CODE>.</B> I think having some address
equivalency functions would be valuable additions to
<I>Majordomo</I>.
<P>
<LI><B><CODE>htmlinfo/newhtmlinfo</CODE>.</B> Add an <CODE>html</CODE>
command to <I>Majordomo</I> to support an HTML-ized version of the
<CODE>info</CODE> as <CODE>$list.html</CODE>. The HTML file can then
be displayed by <I>MajorCool</I> if present.
</UL>
<HR>
<A HREF="config.htm">[Previous: Config]</A>
<A HREF="support.htm">[Next: Support]</A>
<A HREF=".">[Top: Intro]</A>
<A HREF="..">[Home]</A>
<A HREF="mailto:Bill.Houle@SanDiegoCA.NCR.COM">[Feedback]</A>
</BODY>
</HTML>
syntax highlighted by Code2HTML, v. 0.9.1