If one is using MIME to pass around material in which there's
considerable internal structure, such as Hypercard stacks or HTML (for
example), why isn't it better to register and use the specific application
rather than to try to make MIME itself handle that level of complexity?
I don't know enough about Hypercard stacks to answer the question for that
case. But people talk about them as if hypercard thingys are shipped around
in "stacks", with an internal structure that's specific to Hypercard. I've
never heard anyone talk about ftp-ing a single Hypercard page. So maybe it
makes sense to ship around a whole hypercard stack as a single MIME object.
This is all very dependent on the application you are talking about as well as
how it represents its data on the platforms where it is used.
Quite a large number of applicatios use a single file on all platforms.
(Sometimes the format is the same everywhere, in other cases unfortunately it
isn't.) In this case there's no point in breaking out the components of the
file into separate parts in a multipart structure.
Other applications use groups of files. (This is true of many markup languages,
for example.) In this case it may make a lot of sense to put each of the
components inside of a multipart/related object. Most such applications are
inherently multi-file and don't provide a way to package up all their
components in a single bundle. (The only format I know of that has such a
packaging scheme is DDIF and its DOTS packages.)
And then there are things that lie in between the two extremes. Appledouble,
for example, is the way it is because Macintosh files are multipart entities,
and the data part is meaningful by itself on non-Mac platforms. (I suspect that
Windows NT will give rise to some interesting variations eventually, since its
files can contain an arbitrary number of separate "forks".)
In the final analysis it is all a matter of thinking through the engineering
tradeoffs. Monolithic object formats have their place, as do sophisticated uses
of MIME multipart objects.
Ned