Hi Markus!

> Hi Goran,
>
>>> So some developers might be interested in the "naked"
>>> SmaCC Development, but I strongly believe that the end
>>> user thinks and should be able to think in terms of the
>>> whole enchilada, when he thinks "package".
>>
>> Of course. The configs aren't even meant to be "selected" and most of
>> the time not even interesting to look at. The idea is that they simply
>> are in the map and given a selection of a package (or typically
>> several)
>> SM (or specifically the engine, which doesn't need to be part of SM)
>> can
>> calculate all needed prereqs using these configs.
>>
> Good. Then I think I just have a "naming" problem. And a problem with

That may be. I used the word "package configuration" because I think that
is what it is - a description of the environment/configuration needed for
a certain package to be happy that someone has verified. :)
We could also call it a "package prerequisite list" or "tested package
environment" etc.
> the
> mismatch between the GUI and the model, which I generally think to be

I wouldn't say "mismatch". In fact - the UI doesn't exist yet! :) The UI
will clearly show the pconfigs, because they will be a special case of
what I call "resources" - a resource is more or less an object that you
can "attach"/"associate" with another object in SM. Like an "attachment".
So they will be clearly visible. But we may still have "shortcut UIs"
making certain tasks easier and faster to accomplish.
> well designed, if they are isomorphic, which certainly and logically
> does
> not mean, that they are bad designed if they are not. Just a question
> of probability...

Sure, the only thing I wanted to point out is that there doesn't *need* to
be any "extra steps" when you publish a release.
> So to summarize: The user of SM thinks of packages, which are dependent
> on each other and are functional complete, but the developer of
> packages has to know that they in fact should be _independent_ and that
> he has to create a configuration for it, right?

Not sure exactly what you are trying to say. IMHO both should be aware of
the model. We have package releases - they are "the code" and nothing
more.
They depend on each other. Those dependencies are described in package
configs that are associated with the release. A release can have multiple
of those. What is the conceptual problem?
In other words, let's look at a car:

The packages are the different parts of the car. Wheel, engine, door.
The package configs are partial blueprints. One blueprint is for the
carburator showing which pieces you need to hook into it for it to work.
Another is for the engine showing how it needs to be connected to the fuel
tank, the battery and whatever.
The engine doesn't "know" what to connect to it. :-) And frankly - I can
hook up the engine to a variety of stuff and it will still work fine. I
can even put in my boat.
IMHO the model isn't hard to grasp at all, not even for users. I mean
"Hey, here is Seaside!" I wonder what it needs to work. Ok, Avi has
attached a config saying Squeak3.6 + KomHttpServer 6.2. And another saying
Squeak3.6 + KomHttpServer 6.1. Ok, good - two different configs that he
has tested it with. And hey, Göran has attached a third config saying it
also works with Squeak3.7 + KomHttpServer 6.2.

>>>> Putting it inside the package only works for the package formats
>>>> that "support" that. SM handles packages in a variety of formats. I
>>>> don't want to invent different ways of embedding this into these
>>>> formats.
>>>
>>> I thought we wanted to establish a new, maybe better standard now?
>>> There are also Projects on SM, and they will be certainly difficult
>>> to enhance.
>>
>> Well, AFAICT we don't really need a new standard for code packages.
>> Really. We already have Changesets, .st-fileouts and Monticello. There
>> is no need for yet another format.
>>
>> And we could even be fine without Monticello *in this respect*. <-
>> note emphasis
> Ah, I thought we would use Monticello / integrate it in the core?

That is the plan, yes. And I expressly wrote *in this respect* and even
pointed at those asterisks! Meaning that we actually wouldn't need the
Monticello format in order to have a working dependency resolution enginde
with package releases and interdependencies in SM2.x.
>> I know this may sound like  "flame bait" - but read carefully. :)
> No problem, I can't see any flames. But I forgot to say thank you for
> all
> the great work you are doing. Keep it up, and don't be too frustrated
> of me talker, though also customer, both as developer and user of
> packages, :-)

No problem. And the interest is good. I may sound "tired" but that is just
because I have written about this so many times now. And stupid as I am I
haven't written it down properly in one place. Oh, wait - perhaps I did...
Tada: http://anakin.bluefish.se/gohu/17

> Regards,
>
> Markus

regards, Göran