On Fri, 18 Oct 2002 danielv at netvision.net.il wrote:

> How do I see the differences between the image version and the file
> version (which I understood is the whole point)?

Well, the point for me is more to fileIn the changes than to look at them
- I tend to know what the changes are from the commit log.  So I don't
have a button for viewChanges.  It'll be simple to add one if
you like (probably won't get done until Monday though).

Something else I'd like to add is a "change log" option, that'll show
what the image has that the disk doesn't (instead of the other way
around), and help in producing those commit logs I just mentioned.

> > Does this seem to
> > onerous (or too much of a kludge)?
> Yes :-) for a one class package, definitely. Not intolerable, probably,
> but I'd prefer some lightweight route. Actually, I think it's important
> that there be very near zero overhead from working with packages - that
> keeps the smallest practical package really small.

True.  Although a one-class package is going to reqire its own system
category either way, and once you have a category, adding a second class
to it doesn't seem like a big deal... to me, anyway.

> How about this -
> A registry of regular PackageInfos, that registers the package when it's
> first identified (PackageInfo named: 'SM-Loader' would register it) or
> loaded (means saving it in the fileout as a do-it). This registry + the
> subclasses is the list of packages.

Yeah, I was trying to avoid putting do-its into the fileout; that's one
thing that's nice about having the class, it doesn't require any
special-casing.

Hmm.  Well, does anyone else have an opinion?

Avi