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