Partitioning the image (was Re: Shrinking sucks!)

Doug Way dway at mailcan.com
Tue Feb 15 05:20:59 UTC 2005


An excellent summary of the PI situation, Ned. :)  Whew.

You're right that there does need to be some sort of canonical file 
format representing a PI that can be loaded and saved.

I'm still thinking about whether the SMPackage metadata needs to be 
stored in the saved package file... I suppose some sort of key values 
or ID at least would need to be stored to enable lookup of the 
SMPackage.  (Or you could just store all the SMPackage metadata.)

- Doug


On Monday, February 14, 2005, at 11:35 AM, Ned Konz wrote:

> On Monday 14 February 2005 3:18 am, stéphane ducasse wrote:
>>> Btw, the whole discussion about PI subclass or not - at this point I
>>> don't have a good opinion.
>>> There are arguments both ways it seems.
>>
>> Yes I do not have any taste yet in any directions...let's learn by
>> doing.
>
> It seems to me (having used PI instances, PI subclasses, and (for a 
> while, I
> think) having had problems maintaining an instance of a PI subclass) 
> that we
> need to lock down at least part of the responsibility of a PI.
>
> I agree with this part of Lex's comment:
>
>> Subclasses are great for experimenting, but if we want to move forward
>> and write a bunch of package-aware tools, we need to commit to a 
>> single
>> model that the tools can rely on.  Experimenters can continue to make
>> subclasses if they want, but the tool-writers shouldn't need to deal
>> with arbitrary changes.  
> [...]
>> It looks like people have a pretty good feel what should go into a
>> PackageInfo at this point.  The standard #classes, etc., methods are
>> very good I think.
>
> From what I think I know and have heard, it seems like a PI:
>
> * Must be able to list the classes that its package introduces (with 
> the
> assumption that the package includes the entire contents of those 
> classes,
> minus explicit extension methods from other packages)
>
> * Must be able to list the extension methods that its package 
> introduces
> (which of course implies a dependency on some other classes)
>
> * May be able to report explicit dependencies on other packages 
> (perhaps
> including version dependencies)
>
> * May be able to provide other metadata about the package, including 
> (some
> of?) the data needed for the package-level SM card.
>
> * May be able to provide or point to package installation or 
> deinstallation
> methods.
>
> * May be able to provide or point to other utility methods like old 
> instance
> migration, etc.
>
> But whether or not you use subclasses, the problem of actually 
> instantiating a
> PI to use it remains.
>
> Right now PIs come into being as soon as you tell a tool like the MC 
> browser
> the name of a package. Because they can map the package name into a 
> list of
> class categories (and hence classes) and can also spot extension method
> categories in other classes, they can at least enumerate their 
> contents.
>
> This satisfies the first two "must" responsibilities above, but 
> doesn't touch
> any of the others.
>
> Going further than those two behaviors would require loading additional
> information from somewhere. The obvious sources of that information 
> include:
>
> 1. a package file
> 2. a registry entry somewhere on the net (SM, MC, etc.)
> 3. direct communication with the source of the package (like for 
> instance
> custom HTTP headers or other response to a DAV-like query to the 
> server on
> which the package lives)
>
> *Requiring* #2 or #3 means that we're going to prevent one of the 
> modes of
> working that we've been comfortable with in the past: easy and casual
> distribution of package files via email or other means (FTP servers,
> downloads from a Swiki, etc.).
>
> I think it would be a mistake to lose that ease.
>
> The reason that each .mcz file carries around with it its entire 
> ancestry is
> to make it possible to email a single .mcz file and have it immediately
> usable. If you happen to have some of its ancestors in hand, that 
> gives you
> more usable information (you can look at version changes and do 
> merges, for
> instance). You can browse a MCZ file without loading it, and see not 
> only its
> code but its ancestry and dependencies on other MC packages.
>
> CS files, of course, have much less file-level metadata (limited to 
> preamble,
> postscript, and version stamp). But we have made tools that use both 
> the
> date/version stamp (Conflict Checker) and allow you to browse the 
> actual
> contents without loading the code.
>
> I think that we should allow but not require #2 or #3. That is, I 
> believe that
> *all* package-level metadata should be *able to be* included in a PI, 
> and
> that it should be possible to read a PI from a package file without 
> loading
> that package's (non-PI) code or prerequisites.
>
> Lex also said:
>> And thus, Joe Developer shouldn't be making a  subclass, either, if 
>> they
> want the standard tools to work with their package.
>
> Whether or not we allow PI subclasses doesn't much matter much if we 
> made the
> standard tools able to instantiate PIs from a package file. In the 
> case of a
> PI subclass, obviously its code would have to be loaded and installed 
> from
> the file first. But I don't see this as too much of a problem, except 
> that if
> the PI wants to provide other services it would tend to be dependent 
> on other
> (as yet unloaded) code in the package file.
>
> But in the interest of simplicity, I'd be in favor of not supporting 
> that
> model, and just coming up with some way to instantiate a PI from a 
> package
> file without having to compile any code.
>
> And Lex also said:
>>  Also, all PI's should have an optional link to a SM
>> entry (and, if we want to be serious about making stable releases, a
>> Universes entry).  All packages should have installation and
>> deinstallation code.  (and re-configure code....)
>
> If the PI is allowed to carry with it the metadata that is necessary 
> to create
> a new SM entry (as well as being able to link to an existing SM entry) 
> then
> we can decouple the tasks of package creation and SM registration, and 
> can
> allow automatic registration based on the contents of sufficiently well
> identified packages.
>
> So what are we missing? Easy: we don't at present have a package
> representation that includes a standard way to hold the information 
> necessary
> to create a PI instance.
>
> My suggestion, then, is this:
>
> * We should define the required interface of a PI.
>
> * We should keep the existing name-based (class category/*method 
> category
> based) simple PI definition for cases where there are not yet package 
> files,
> or where PI instances have not been added to package files. This would 
> give
> us compatibility with existing file formats.
>
> * We should require that a PI be able to provide its basic services 
> without
> having to compile custom code (this doesn't disallow PI subclasses, 
> but might
> require that PIs created from files get converted into instances of the
> appropriate subclass upon loading the package).
>
> * We should come up with a standard way to serialize and deserialize PI
> instances. And that serialized representation should probably be 
> textual, so
> that it can be humanly readable, mailable without damage, and easily 
> included
> in changesets and other less-structured files.
>
> * We might come up with a way to add this serialized PI data to the 
> preamble
> or postscript of change sets, so that we can leverage existing tools 
> and
> still be backwards-compatible.
>
> * We have two existing Zip file formats that represent or can represent
> packages: SAR and MCZ (and MCD too, I guess). Both of these should 
> define
> optional members to hold the serialized PI. This would give us 
> backwards
> compatibility (those members would be ignored by older versions of MC 
> or
> SARInstaller).
>
> * We should modify existing tools (MC browser, SARInstaller, Code 
> browser, CS
> loader, etc.) to support instantiating PI instances from package files 
> where
> possible.
>
> * We should allow well-defined package-level metadata to be optionally
> included in a PI. This would, for instance, let us create new SM cards 
> from
> package files that include sufficient metadata.
>
> * We should allow future extension of the metadata carried in a PI 
> (perhaps by
> allowing arbitrary name/value pairs) in such a way that we don't break
> backwards compatibility.
>
> What do you all think?
> -- 
> Ned Konz
> http://bike-nomad.com/squeak/
>




More information about the Squeak-dev mailing list