RE: MIME, Windows CE and the Volkswagen Thing

["Ian Ferrell (Exchange)" <ianf@xxxxxxxxxxxxxxxxxxxxxx>]

Speaking for the Windows CE numbers:

Windows CE devices (Handheld PCs) typically come with 2 or 4 meg of RAM
and 4meg ROM. The actual number is left as an exercise for the
particular OEM implementation. In practice, I haven't seen less than
2meg RAM due to OEM features, component availability and user price
points. Device RAM is used for file system storage and application data.
Applications like Pocket Mail and Schedule+ execute-in-place in ROM so
the RAM impact is minimal; we're talking 10s of K per app for data as
needed. App-in-ROM size ranges from Pocket Mail (385k) to the calendar
(160k). The PIM pieces share several DLLs, so exact size is a bit
difficult to determine.

Code size is absolutely critical for us; we only get a certain amount of
memory real estate and have to balance features/code requirements within
that space. As a result, code-sharing is key and a primary reason that
the PIM apps have several DLLs to share functions and features between
the apps. I imagine a number of other "light" platforms like the
proposed NetPC/Network computers, PDAs and future Windows CE/Handheld PC
family members have similar, if not tighter, constraints and goals.

I agree 110% that handheld devices cannot ignore the Internet. Internet
connectivity means web access and email, and that means MIME, HTML, et
al. on the device. Building our design on top of existing Internet
standards and combining code translates into smaller apps on these
machines, less time bringing developers up to speed on
Yet-Another-Framework, fewer bugs since there is less code and a greater
understanding of the design, and feature inheritance when new
capabilities like S/MIME become part of the core MIME handler. Each of
these bonuses translates directly into measurable benefits for the
customer. Given that we're going to have MIME on the device for email
and Pocket IE, we'd prefer to leave the implementation as close to MIME
as possible (i.e. data types, content tagging, extension mechanisms,
etc.) so we don't have to write extra handlers and wrapper crackers
unless there is a tangible value-add for doing so.

In a kind-of-unrelated-note, I enjoyed Robert Moskowitz's post on USCAR
removing "non-value-add" designs from automobile parts. I drive a 1973
Volkswagen Thing (designed with ~85% ubiquitous Volkswagen Beetle parts
and 15% ultra-rare Volkswagen Thing-specific parts of dubious value-add)
so I feel this pain every time I have to ship a rear brake drum or the
like to Seattle from some obscure German military parts depot. (And
please don't bring up trying to find an OEM vehicle jack or
side-curtains... :-) While this initiative won't help my car, it will
hopefully shorten the line at my local auto-parts counter so I get to
the "you need a rear brake drum for your *what*?" stage a lot quicker...

Ian Ferrell
Windows CE Mail and Scheduling Program Manager

_____________________
"How about Christmas?" inquired Joe doubtfully.
"We shouldn't want to miss Christmas, should we?"
"Worrying about your presents?" Frank asked.
"I'd hate to miss them..." replied Joe.
The Hardy Boys wait up for Santa Claus
in The Mystery of Cabin Island, original text, 1929, p31.

	-----Original Message-----
	From:	owner-ietf-calendar@imc.org
[SMTP:owner-ietf-calendar@imc.org] On Behalf Of Ken Shan
	Sent:	Sunday, December 08, 1996 11:47 AM
	To:	Paul.Rarey@Clorox.com
	Cc:	ietf-calendar@imc.org
	Subject:	Re: MIME as a vCalendar element separator - bad
move...

	Paul Rarey wrote:

	> Alec Dun wrote:

	> > 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.

	> It's hard to say no to a statement like that. It would seem a
reusable
	> JAVA based MIME parser would help such that each application
specific
	> component wouldn't have to include it's own MIME parser. 

	Exactly how much code (in Java, say) is a MIME parser?  How much
code
	is a hack on top of the MIME parser, for those who have it, to
make it
	translate BEGIN/END markers into recursive MIME objects?

	It was argued that no personal digital assistants can ignore the
	Internet today.  Excuse my ignorance on this matter, but how
much
	memory does a typical Windows CE palmtop machine has?  How much
memory
	would be used on a typical Windows CE palmtop in order to
implement
	MIME parsing?  How much would be used to implement BEGIN/END
parsing?
	How much memory does Exchange and Schedule+ occupy on a typical
	Windows CE machine?  I think some hard numbers would help
greatly.

	-- 
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.