RE: MIME as an appointment element separator - good move...

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

> ----------
> From: 	Ken Shan[SMTP:ken@digitas.org]
> Sent: 	Sunday, December 8, 1996 6:57 PM
> To: 	Alec Dun
> Cc: 	Paul.Rarey@Clorox.com; ietf-calendar@imc.org
> Subject: 	Re: MIME as an appointment element separator - good
> move...
> 
> Alec Dun wrote:
> 
> > The issue of hacking begin/end on top of MIME isn't one of how long
> it
> > would take to write, but rather that of the extra code involved that
> > will unnecessarily consume additional memory.  Imagine if every MIME
> > body part needed a special parser how horrible the bloat would be.
> I
> > wanted to try to avoid that if possible so our products can be
> small.
> 
> I *was* asking how much extra code would be involved, and how much
> additional memory would be consumed, if BEGIN/END are to be parsed.
> From what you say it seems that I have vastly underestimated the
> amount of code needed to translate BEGIN/END into recursive MIME
> parts.  However, this translation seems fairly straightforward to me,
> and I still don't see where I have estimated wrong.
> 
The point is that the code is unnecessary.

> > The least expensive windows CE machine has 2Mb of RAM, and 4Mb of
> ROM.
> > I don't have figures for the other ones you asked about.
> 
> Thanks for the figures.  How much code do you think adding BEGIN/END
> support would cost?  Would that fit into the 2Mb of RAM (let's say not
> everybody want their calendaring app burned into their palmtop's ROM)?
> 
The unnecessary memory that is consumed here can not be used by other
apps.  The number of apps and amount of data I can use on my machine
will be reduced by the additional code.  If all the apps running on my
machine have the drawback of poor code reuse, then it makes a
significant difference.

> -- 
> blue | Ken; Shan, Chung-chieh; Sian7, Tiong1-kiat8;
> ken@digitas.harvard.edu.
>  ()  | Your code today becomes the mind tomorrow:  Your plan its
> means,
>  /\  | your dream its ends, your ideal its elegance.  Hack on.
>