Edit | Rename | Changes | History | Upload | Download | Back to Top |
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 |