>>> My choice of example is to simply start at the beginning.
>>>
>>> 1. The current protocol, requires explicit registration and
>>> deregistration.
>>>
>>> 2. When you want to slice up the image into small pieces it is a  
>>> pain to
>>> have a dependency elsewhere. Smalltalk/SmalltalkImage initialize  
>>> is a prime
>>> example, where the Balloon-Collections could be removed (from  
>>> cuis), but for
>>> their mention here.
>>>
>>> 3. the addToStartUpList: aClass after:  
>>> anotherCompletelyUnrelatedClass
>>> idiom is simply asking for one package to be unnecessarily  
>>> dependent upon
>>> another, just for the sake of setting the ordering.
>>>
>>> 4. The implementation code is fairly complex, compared to the  
>>> alternative.
>>> There are some fringe cases and validation cases dotted around the  
>>> image
>>> which would not be necessary. (e.g. on renaming or removing a  
>>> class).
>>
>> +1 to all of the reasoning. Two things I'd do in your  
>> implementation is to
>> a) use symbolic names for the priorities (so that one can say
>> NormalLaunchPriority, EarlySystemStartup etc. instead of numbers)  
>> and b)
>> have a unique order inside a priority group (say alphabetical) so  
>> that
>> there's *some* defined order by which things get executed. The  
>> latter avoids
>> suprises if there happens to be a dependency between  
>> initializations; at
>> least it'll be always the same and you can plan for it accordingly.
>>
>> BTW, I'm *very* happy to see that you've found a way by which you  
>> feel
>> comfortable contributing to Squeak. Your help is most welcome.
>>
>
> I am a bit concerned about logic of prioritization of startup/ 
> shutdown lists.
> You can't implement the simplest 'run before anything else' rule,
> since there's no guarantees that any other package would not want to
> do the same and hence you'll get a conflict.

Within "small rodents" (Cuis and derived images) the InstallStream's  
mechanism enables the basic structure of the image you are building to  
be fairly well crafted on top of the kernel.

In particular it is not assumed that packages like seaside will load  
without a fight, so there is a definite place in which to fine tune  
different packages as they load. For example we will see if we can  
have a loader that can rename classes, or understands real or fake  
namespaces.
So the worry of a conflict is not there for me.

> Maybe, a System should throw an error, if it finds that there are two
> or more things which want to run on same priority, and signal the
> user/developer to solve a conflict before saving an image.

Possible, but Andreas is preferring quantised priorities, whereas I  
kind of preferred the numeric fluid version, because it had a simpler  
implementation. In reality most packages don't care that much and just  
add themselves to the end of the list.

This would be priority #normal I guess.

> Then, at startup, a system won't need to guess what follows what,
> since it is _always_ instructed by user explicitly.

That was my expectation, though I was not expecting any check to be  
necessary.

> So, a proposal is, that classes , which want to take part in
> startup/shutdown phases providing a 'guessed' priority.

Currently I am adopting Andreas idea, but you are still free to use a  
manual number if you need to tweak it.
Priorities I have so far are:

	^ IdentityDictionary new
		at: #first put: 0; "reserved for Delay"
		at: #earliest put: 10;	
		at: #earlier put: 100;
		at: #early put: 200;	
		at: #normal put: 500;
		at: #late put: 800;		
		at: #later put: 900;
		at: #latest put: 990;	
		at: #last put: 999;  "reserved for Delay"
		yourself.
	
sorting is done, on priority first then class name.

regards

Keith