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.

> Perhaps configurations should live on their own and the list of 
> configurations for a given package is simply any configuration that 
> includes that package (rather than have an explicit relationship 
> there).

Hmmmm... well, then they suddenly loose their semantics. Not sure I like
it.

> A simple query can give you all the configurations for a given 
> package (you might add additional filtering options, such as 
> ranking/sorting configurations by maintainer, popularity, ones that 
> include the most recent package versions, etc).  You could make it 

Indeed we can. As you may note - the model I am proposing is meant to be
"easy" to analyze by an engine etc.

> optional to give a configuration a name and version number (otherwise, 
> it could be identified by UUID).  In the context of configurations, a 

Configs are intended to simply be a special case of an SMResource - and
all resources have name, UUID, version and some other things.

> version number is really more of a convenience for us humans (it allows 
> us to group similar configurations together under the same name).

Yes, or to see that a config we are using has changed - this means the
owner has decided to "correct" it.

> As for a configuration being able to specify other configurations, it's 
> probably not necessary, but a tool that would allow you pull in 
> (subsume) all the package versions from another configuration when 
> defining a new configuration would be useful.

Yes, that was how I wanted to do it.

>  It might even be 
> preferrable to allowing configurations to specify other configurations. 

Hmmm, I hesitate about that. Because then the versioning issue of
configs suddenly become more complex. A config would "change" if one the
configs it references changes etc. Nah, don't like it.

> With Envy I find that when you start to get a tree of config maps, you 
> most often end up synchronizing the versions of all the required maps 
> with your top level map...when opening up maps for development, it keeps 
> the timestamps in sync (making it easy to see which config maps are 
> related to a given stream of development) and when versioning, you 
> version the maps all the way down with a given version name.  Thus, the 
> lower level config maps will tend to have different versions for each 
> higher level config map for which it is a required map.  You may as well 
> just subsume the lower level config map's package versions into the 
> higher level config map and just version it (but if you need to maintain 
> the lower level maps in sync with the higher level config maps for the 
> purposes of independent loading, then you'll need version the lower 
> level config maps, then subsume those into the higher level config 
> map)...basically, I think it's a wash either way, but not allowing 
> nested configurations does force you to deal with and correct any 
> inconsistencies up front (in Envy, you can have multiple required maps 
> that may have different versions of the same application released, thus 
> creating an inconsistency).

Ehh... in short - I don't think Envy is a good rolemodel here. It is
much too complex.
And I don't think it tries to solve the same problem. SM is much more
coarse granular, and probable a range of other differences.

> One additional thought:  by not keeping any pre-requisite information in 
> the package itself (not even a listing of pre-req declarations) you are 
> able to handle situations where a pre-requisite morphs from a single 
> package into multiple packages.  Here's an example:
> 
> WizBangTcpService 1.0 owned by xyz
>     (Comanche 5.1) owned by xyz
> 
> WizBangNetService depends on Comanche for two things, its service 
> management capability, and its packaging enhancements.  Now lets suppose 
> that Comanche gets refactored into several smaller packages rather than 
> one large one...we could add the following configuration:
> 
> WizBangTcpService 1.0 owned by xyz
>      (Comanche 5.1) owned by xyz
>      (KomPackaging 1.0, KomServices 1.0) owned by xyz
> 
> The fact that we've not declared or even enumerated the package 
> pre-requisites in the package itself allows us to handle this situation 
> cleanly.  And, I expect this situation to happen quite often as we get 
> better and better packaging tools.

Yes! Thanks for that use case.

> - Stephen

regards, Göran