goran.krampe at bluefish.se wrote:

>Stephen Pair <stephen at pairhome.net> wrote:
>  
>
>>gohu at bluefish.se wrote:
>>
>>    
>>
>>>Anyway, I hope the above model seems simple and capable. It is much like
>>>Stephen's (but configs don't have versions and can't refer to other
>>>configs - would be interesting to hear Stephen's words on that). 
>>>      
>>>
>>[Lots of stuff snipped...see previous email for details about the model]
>>
>>Now this sounds interesting...as I had thought about configurations, it 
>>bothered me that it seemed every package would also have a configuration 
>>(i.e. you would have a KomHttpServer package and a KomHttpServer 
>>configuration).  With this model, that no longer is an issue.  However, 
>>I think you still need a mechanism for naming a configuration so that a 
>>configuration can be easily referenced (i.e. if Seaside 2.1's three 
>>configs were named A, B, and C, then you would refer to conf A as 
>>"Seaside 2.1 configuration A")...or, were you planning to use UUIDs or 
>>something?
>>    
>>
>
>They will both have UUIDs and names. And actually also a "version" field
>- but that is only as in SM1.x - meaning that it knows its *current*
>version, but nothing about older versions.
>
>As you can see a config describes ONE possible setup for one specific
>package release. Since the releases will be immutable (not enforced, but
>I assume we all will abide) a config can only be "correct" or
>"incorrect" - meaning that there is no point in remembering an old
>version of a specific config.
>
>Btw, I also realized that one way of looking at all this is that the
>configs are "inside" the package releases - well, not inside the actual
>file holding the code - but surely "inside" the SMPackageRelease object
>in the map. Meaning that they aren't shared by others etc.
>
>  
>
>>But, another use of configurations (that you may not be accounting for)  
>>is to specify some arbitrary grouping of packages that you want to load 
>>together and use.  Such configurations might not be naturally associated 
>>with any single package.  For example, I want a configuration that loads 
>>both Seaside and HttpView together...would I attach that to Seaside?  or 
>>HttpView?  Or both?
>>    
>>
>
>I can see two solutions - either a "virtual package" that has no code,
>but has configs attached.
>
>Or a load script.
>
>Personally I think this isn't really a config - because it doesn't
>specify package releases that are *needed* to ensure some other package
>release works. So we would be "abusing" the model a bit.
>
>A load script on the other hand seems pretty perfect. :) And sure, if we
>would like to introduce a more "declarative" object for this - we can do
>that.
>  
>

I think you need to be careful that "load scripts" and "configs" are 
sufficiently different animals that you're not just replicating 
everything a config does in a load script.  For example, I will want to 
simply select one or more configs and say "load them" without needing to 
define a load script.  Conversely, when I do define a load script, I'll 
simply want to identify one or more configs and perhaps packages to load 
(together with an ordering of those things).  Will a config carry enough 
information (i.e. a load order) such that a load script could be created 
on the fly for a config?  Perhaps you could elaborate on exactly how you 
envision load scripts working.

If package A has a config that specifies KomHttpServer 6.2, does that 
also imply all pre-requisites of KomHttpServer 6.2?  If so, do you need 
to be explicit about which KomHttpServer 6.2 config you are talking 
about when specifying the config for package A?  Or, does a load script 
do that?  For example, would the load script specify package A (and some 
config), KomHttpServer 6.2 (and one of its configs)?  If that's the 
case, then configs don't really specify a completely working assembly of 
packages (i.e. certain configs of KomHttpServer 6.2 may not work with 
package A's config).

It seems to me that your definition of a config may really just a 
listing of immediate pre-requisites for a package.  Which, in 
combination with load scripts and good load tools, might work.  Not sure 
I would call these "configs" though.

- Stephen