Future Direction
MajorCool 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 Majordomo
2.0 product.
Design Concerns
- Authentication -- Using the Web to augment a mail-based
system is always problematic. Barring the use of htpasswd or
other server-based authentication, there is no way to trust that the
user is whom [s]he says [s]he is. For MajorCool, a decision was
made to "bite the bullet" and trust that the end-user can correctly
specify his/her e-mail address (or name).
$trust_identity
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 httpd
REMOTE_HOST and REMOTE_ADDRESS CGI variables are sent as
part of address comments in the simulated e-mail header. Thus,
Majordomo maintains an accurate Log of who submitted Web
requests. If authentication can be improved in any way, it can only
serve the users better.
- Results Feedback -- The single biggest limitation of the
chosen design is the fact that Majordomo still sends final
results of "change" actions via e-mail. Although MajorCool does
a majority of the front-end work interactively, the interpretation of
the Majordomo modify actions is not possible and the user must
instead watch for e-mail confirmation. An API interface to
Majordomo would be monumentally useful, allowing actions to be
performed with the results returned as a function call return rather
than assuming e-mail.
- Performance -- Because Majordomo is ultimately used
to perform any actual work for list or configuration changes, the
MajorCool app is at the mercy of how fast Majordomo can
process the submitted commands. Given this and the above Feedback
limitation, it may be more appropriate to simply hand off the tasks to
Majordomo as a background process and not have MajorCool
wait for command completion as it currently does. In other words, is
the 'trace' output really necessary?
Bugs/Misfeatures/ToDo
- Document returns no data. 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.
- Word-wrap of the
info
file. Despite the use
of WRAP=PHYSICAL
and the Preferences setting to control
it, wrapping of the file is not working correctly.
- Archive list & file
get
interface. The next
logical step would be to provide access to Majordomo list archives,
possibly even augmented by HTML formatting via tools such as
HyperMail or
MHonArc.
- Bypass the Key Cache. The use of the key cache was
necessitated by the inherent slowness of the
get_config()
API call when plodding through all lists that the server offers.
When/if Majordomo moves to a more efficient file interface, we
will be able to dump the caching, thus eliminating an extra
installation step.
- More complete
is_advertised()
address matching.
The is_advertised()
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.
- Cross-pollinate
siteaddr()
and sort
by_siteaddr
. I think having some address
equivalency functions would be valuable additions to
Majordomo.
htmlinfo/newhtmlinfo
. Add an html
command to Majordomo to support an HTML-ized version of the
info
as $list.html
. The HTML file can then
be displayed by MajorCool if present.
[Previous: Config]
[Next: Support]
[Top: Intro]
[Home]
[Feedback]