Warning: opinions, little to do with qmail or maildir.
Bruce Guenter wrote:
> On Sat, Jan 15, 2000 at 12:25:09PM -0500, Greg Owen wrote:
> > 1) Integrate support for some sort of calendaring. I've
> > run both IMAP and Exchange based environments, and for all
> > its faults, the integrated calendaring that Exchange does
> > is extremely useful. None of the web-based calendaring
> > systems I've seen compare.
>
> As much as I would like scheduling, this is an "mailbox"
> program, which handles email. I believe that proper support
> for scheduling would add too much to the protocol, given that
> this is supposed to be "simple".
True. I was attacking the question not from the "what simple things
can we add" POV, but the "if you were designing a replacement, what needs
would you try to fulfill?"
A good calendaring system requires that users receive requests for
meetings and can answer them, and have trouble screwing them up (i.e.
putting the metainfo in the subject line is easy to screw up). Email is the
ideal medium for this communication, because it meshes well with our
existing work patterns. However, as I see it, there are three types of
calendar systems:
1) Those that integrate so closely with email that the user can't screw it
up
2) Those that can't integrate closely enough with email, and users screw it
up
3) Those that don't integrate with email, and are hard to use.
I don't expect there is much sympathy for my sort of "big system"
thinking on this list. But there are cases where throwing more into the pot
results in a win. IMAP and SMTP are an example - IMAP is a mailbox access
protocol only. It does not support sending mail. How much of the traffic
on this list deals with allowing mail sending without relaying? One could
conceivably have looked at SMTP when writing the IMAP spec and said, "Gee,
the lack of authentication in SMTP is a real pain in the ass. Let's add a
POST command that allows insertion of mail from an authenticated IMAP user,
then we don't have to worry about relaying issues in SMTP." Reinventing the
wheel? Maybe. But sometimes you should consider how well the wheel works
on today's vehicles and roads.
> > 3) Integrate configuration info onto the server, like ACAP
> > or IMSP tries to do. All you should need to tell your client
> > is you username, password, and server; it'll go do the rest
> > to the best of its abilities.
>
> Do you have an URL for a specification of ACAP or IMSP? I've never
> heard of them, but what you've described is a good idea.
A good page for ACAP is http://asg.web.cmu.edu/acap/. ACAP is
derived from IMSP; there's an RFC for the latter at
http://asg.web.cmu.edu/cyrus/rfc/imsp.html.
I'm not sure how far ACAP is moving forward. Presumably that'll
depend on whether or not people start trying to add this sort of
functionality into directory services as they start blooming.
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
