Celeste design (was Re: [ENH] Celeste attachments/displaying a thingie)
Lex Spoon
lex at cc.gatech.edu
Tue May 2 03:43:32 UTC 2000
danielv at netvision.net.il wrote:
> Sorry if this is a bad time to mention it, but it seemed to me that
> MIMEDocument is a clear candidate for unification with MIMEPart, while
> leaving MailMessage as a (mostly) dumb container.
> This partitioning seemed natural because the structured content might
> not arrive via mail, though it doesn't seem critical.
>
> Either way, do you agree that MIMEDoc should go? (I'm feeling the woes
> of postponing my refactoring... ;-)
>
Unifying all these notions of "data we got from the Internet" definately
seems like a good idea. Since lots of Internet protocols copy the
format of mail messages for this, MailMessage seems like a reasonable
place to focus.
As it seems to me, a MIMEPart is itself a MailMessage--it happens to be
one of the parts of an outer message, but it's behavior is the same.
Furthermore, any MIMEDocument can be replaced by a MailMessage--just add
an appropriate Content-type: header.
So, why not collapse all three classes into MailMessage? Perhaps we
should at least rename "MailMessage" to reflect it's more general role,
but I can't think of a good name for it. The Internet really does
revolve around chunks of data in email format, so in a way we'd just be
calling it the way it is.
Incidentally, the best way in Smalltalk to have structured content, has
to be with an object and a class pointer. Let's just use this MIME
stuff for talking to the Internet, and change incoming data to Smalltalk
objects as quickly as possible.
> About giving MailMessage content-sensitive behavior, I'd propose a
> Strategy pattern. Have a dictionary from some combination of
> content-type and disposition to appropriate strategy classes, and have
> every MailMessage choose it's own, and delegate content-type sensitive
> actions to it. This would include it's favorite display, a menu of
> appropriate actions and so forth.
>
Yes, exactly, let's have an object which defines the strategy for each
content-type. The harder question is still there, though: what exactly
should the strategies include? Converting content to a morph, perhaps?
Certainly this works well for text, HTML, images, and flash. Hmm,
tempting....
-Lex
More information about the Squeak-dev
mailing list
|