[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Responding to calendar requests

From: Mike O'Dell
Subject: Re: [Nmh-workers] Responding to calendar requests
Date: Fri, 26 Apr 2013 23:13:49 -0400

but responding to calendar requests
*is* common for a lot of people, even if it isn't for you.
that doesn't mean it's OK to make life miserable.

the point is not how to make "repl" do calendar replies.

the point is what "repl" means in the face of documents
which are more complex than 140 bytes of ASCII, and how that
can be extensible *based on the message document*
without sacrificing the simplicity of the "repl"
interface and kludging up the code with lots of
special cases.

we already have other commands which have scriptural
programming - the format files. so far, they are 
pretty much similar even if the syntax makes 
sendmail config files look attractive.

and i agree with the notion of a multiplexor model,
almost but not quite, because it doesn't explicitly
capture the notion that the documents in question are
discriminated vari-adic unions and the implicit type
system requires extensibility.  it has some of that
by the header: machinery in the .mh_profile but it's
hardly general nor does it generalize the notion
of nested document components: mime parts, digests,
nested replies, etc.

my point is that if you stand back 20 paces and squint,
a bunch of these different pieces start looking pretty
similar, and there is a lot of almost-similar code.

the question i'm posing is whether there is "grand unification"
which could be achieved? often, when something grows like
email has grown, the "natural form" of the abstraction layering
becomes inverted. back when mail was "headers and body",
ok, hack hack hack....

maybe the form is now segment-segment-segment where most
are mime segments (handled by some internal and some external
processors, some are "other" segments, and some can be
"header" segments. process it "backwards" from what it
now does. that captures the muxing and demuxing operations
more naturally, i suggest, and that inversion of concerns
might make things a bit less contorted.

NOTE: i'm not suggesting having this done by next tuesday!

rather, something to think about while enjoying your favorite


reply via email to

[Prev in Thread] Current Thread [Next in Thread]