RE: MIME as a vCalendar element separator - bad move...

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

Small devices like Sharp are a prime example.  They want to handle
e-mail and appointements sent thru e-mail.  They are already going to
need to parse MIME messages (to handle e-mail).  They want to be able
to price their products competitively by providing as much
functionality as possible with a minimum amount of memory.

I used to have a similar attitude about working set, what's 50k here,
what's 50k there until I talked to customers who are trying to run on
highly memory constrained machines.  The reality is that every little
bit counts.  If you don't use that memory, the user can run another
program or buy a cheaper machine with less memory.  Small products are
an attitude.

Also, Ron, keep in mind that DLL size and working set are very
different.  Pages are allocated/pulled in as 4k units (at least on
Win95/NT), so you could consume 24k or 28k or memory, but never 26k of
memory.  When you are using code, there are static and dynamic data
pages as well which are not counted in the size of the DLL.  Often the
memory consumed by a component when you are running it is a fair bit
higher than the DLL size of that component.

Thanks,
Alec.

> ----------
> From:
> owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> behalf of Roland H. Alden[SMTP:ralden@ralden.com]
> Sent: 	Saturday, December 7, 1996 5:44 PM
> To: 	'ietf-calendar@imc.org'
> Subject: 	RE: MIME as a vCalendar element separator - bad move... 
> 
> 
> >...if it was as good as MIME, it would be just as much code as
> MIME).  
> >One key problem is that in all proposals I've seen, you need BOTH
> MIME 
> and vCalendar parsing code.  Wouldn't ...
> 
> Just to put this in proper perspective the core
> parser for vCard and vCalendar from Versit compiles
> to a 26K object code file. An entire DLL (Win95)
> that contains a parse tree API and a bunch of helper
> APIs is 69K. That includes overlap with stuff you'd
> find in a MIME parser, like BASE64 encoder/decoder,
> etc.
> 
> In the context of email clients a full MIME implementation 
> is a given, but the C&S solution will not be MIME alone, the 
> WG must add more stuff to MIME, and if the above measurements 
> are at all indicative it won't amount to much code (the 
> parser won't anyway, I know the apps will be potentially 
> complex).
> 
> However, if a client was a really small PDA like
> device, like a Sharp Wizard, it might credibly
> be able to receive appointments and vCards via an
> infrared port. In THAT scenario having to deal with
> ALL of MIME just to find the appointment and vCards
> might be a lot to ask. I think the SUBSET of MIME
> that we are really talking about on this list would
> not be a problem (it's verbose but it wouldn't greatly
> inflate the code). The problem is, who's going to
> define that subset or explain how it's OK if this
> little device doesn't do "all" of MIME? Are we going
> to have an appendix to the spec that says what's OK
> and what's not? (...uh, it's based on MIME but, uh, 
> you can't really do that...). At some point it's like 
> saying you're going to do Unicode but only support 
> the first 256 characters...
> 
> 
> 
> >----------
> >From: 	Alec Dun[SMTP:AlecDu@Exchange.Microsoft.com]
> >Sent: 	Saturday, December 07, 1996 4:59 PM
> >To: 	Lewis Geer (Exchange); 'Keith Moore'
> >Cc: 	'Mike Weston'; ietf-calendar@imc.org
> >Subject: 	RE: MIME as a vCalendar element separator - bad move... 
> >
> >I would agree about it being easier to parse (and the reason is
> because
> >it doesn't do 1/2 as much, if it was as good as MIME, it would be
> just
> >as much code as MIME).  One key problem is that in all proposals I've
> >seen, you need BOTH MIME and vCalendar parsing code.  Wouldn't we be
> >better off just having MIME?  That way implementers don't have to
> have
> >extra code and understand extra concepts and everything.  It just
> >complicates things.
> >
> >The only argument I've seen so far is a vCalendar backward
> >compatibility argument, but I would rather pay the compatibility
> price
> >(since there isn't really much vCalendar out there) than bloat the
> code
> >with all this extra parsing code.  I think customers want everyone's
> >code to be fast and small so they don't have to buy so much memory
> for
> >their machines.
> >
> >Speak up now if your company likes small, efficient products.
> >
> >- Alec.
> >
> >> ----------
> >> From:
> >> owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> >> behalf of Keith Moore[SMTP:moore@cs.utk.edu]
> >> Sent: 	Friday, December 6, 1996 4:35 PM
> >> To: 	Lewis Geer (Exchange)
> >> Cc: 	'Mike Weston'; ietf-calendar@imc.org; moore@cs.utk.edu
> >> Subject: 	Re: MIME as a vCalendar element separator - bad move... 
> >> 
> >> 
> >> > I have yet to hear a reason why the 
> >> > vcalendar separators are *better* than using MIME.  What
> additional 
> >> > functionality do they give that MIME does not have?
> >> 
> >> vCalendar framing is MUCH easier to parse than MIME.
> >> 
> >> Keith
> >> 
> >
>