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 
the
mismatch between the GUI and the model, which I generally think to be
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...

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?
>>> 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?
> 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, :-)

Regards,

Markus