Edit Rename Changes History Upload Download Back to Top

Discussions


here is a summary taken out of various emails:

Here is our seminal question:

>> Here with doru we are really looking at the way store bundles and 
>> packages works and
>> I was wondering what you were thinking about configurations: ie that 
>> packages do not
>> encode their dependencies but that we can get configurations that 
>> know how to load
>> a set of coherent packages.



Georg
=====
> My inner wish would be find someone who does components "right" like 
> Avi did Web-Applications "right". Current
> Store could be used as feature list. (Actually using a relational 
> database as back-end is a good idea for the acceptance in large 
> corporations).
>
> If you have any idea in this direction I would love to hear from you.

I'm discussing with alan, avi, goran (the guy doing the squeka code, 
assets delivery)
about adding configurations to Store. I think that having dependencies 
inside package
is a problem

I think that using monticello as a starter would be good. I'm sure that
two good guys could really do something really good. But money is needed
as usual. I think that this would be better for them to start from 
scratch
instaed of patching an ugly stuff like that.



Goran view of configurations:
=====================
Well, my use of the word configuration is not the same. This page has a
bunch of my writing on the subject:

        http://anakin.bluefish.se/gohu/17


Well, I am actually coding it! ;) I am using unit tests this time :) and
it looks pretty good sofar.
I am essentially focusing on two use cases:

1. Installing 1-n selected packages into an image in one big swoop.
2. Upgrading 1-n selected packages already installed in an image.

Now, the first one is working but I am refining it. It currently makes a
full search for all possible solutions (recursive combinations of
configurations), including solutions which contains "conflicts" (needing
two different releases of the same package) - because those solutions
can also be used (just pick the newer one) if the user wants to see if
he is lucky.

The idea is that the user picks stuff he wants to add to the image in an
"installation queue" and then says "do it". The system then responds
with a Set of different solutions to select from. It will recommend ONE
solution using some heuristics. A solution is an *ordered* list of
specific package *releases* to install or upgrade to.

The engine of course takes already installed releases into account,
yadda yadda. Btw, this code actually was slightly more challenging than
I initially thought. :)

The second use case is a bit different - typically other heuristics
involved. I am just about to start coding on it - not exactly sure how
it should be handled "the best".

I should be able to have this stuff working within a week or so - the
engine that is. Then I can demo/present it to the list.

Summary of Avi email:
================

>  Have thought about the mail I sent related to dependencies because 
> now with store here we end up
> with a huge mess because this is difficult to handle configurations.

I've thought about it, but it's a hard problem.  I definitely don't 
like the way MC does it right now.

I think what's needed is some very simple interface for Bundle or 
Configuration or PackageGroup or whatever you want to call it, that 
just amounts to returning a list of versions of packages, where this 
isn't even expect to always be the same list if you ask the same object 
multiple times - and then you have a lot of subclasses of this, so one 
that is a very static configuration, one that builds up a dynamic list 
based on some kind of package database like SqueakMap, one that looks 
for the most recent version in a certain repository, and so on.  That 
way if people have configuration problems in the worst case they can 
even build their own subclass of this thing.

But that's a pretty vague description, and I don't have time to 
implement it right now...

Alan
===
> I don't know that ENVY's configuration maps are a particularly good 
> model. They do have an interesting distinction that I think may be 
> important for configurations. That is, that a configuration does not 
> exist as an object in memory. So you don't have issues of what happens 
> if I load this configuration, then the other, and they overlap. This 
> is a problem if you have a bundle-like model, where loading another 
> bundle which contained the same package counts as changes to the 
> first.

May be you should discuss with goran because he is building the 
configurations for Squeak delivery system.

> On the other hand, it always bothered me in ENVY that you had three 
> different concepts: configuration maps, applications/subapps, and 
> prerequisites. All of them basically tell you that when you load X, 
> you also need to load Y. While there are differences, it always seemed 
> to me that there was a single unified concept in there, screaming to 
> get out. But I admit that I never figured out quite what it was.

I think that it would be nice to have a mailing-list to discuss that 
because this is of key importance, and I agree with you that Envy model 
is not good.

> I was doing some vague reading and thinking on how version 
> control/team programming ought to work in general during the summer. 
> In general, I think the idea of streams is important, and at the 
> moment not well represented (neither in Store, ENVY, or the file-based 
> systems I'm familiar with). I always get frustrated when people talk 
> about using "most recent" as a mechanism. Especially because it's 
> usually accompanied by "like ENVY", a system that had absolutely no 
> concept of most recent in it anywhere.

My intuition is that
configuration should be out of package
package should not have dependencies
for release you want to have fixed configurations
for working you want to have the most recent or be lazy

I would like to have a system that says please build a configuration so 
that my system is like it now.

> Something that looked interesting, although I've not used it, just 
> read a bit of their literature, was a system called AccuRev. It was 
> stream-based, and seemed quite clean and simple. Some of their 
> concepts were very file-based and not really applicable, but others 
> seemed quite interesting. In particular, they seemed to have thought 
> about issues of how you nest streams, which is quite tricky.
>
> Most of the ideas I had have gone away, but I hope I have some cryptic 
> notes somewhere that I'll be able to use to figure it out later :-)  
> And for the moment I've primarily been working on how to replicate the 
> existing concepts, not on how to improve them.


Edit Rename Changes History Upload Download Back to Top