I don't have a specific proposal on what to do about SqueakMap and Universes, but my meta-response is: we should use whatever works for the goals we want to solve. I'm hoping the goals can be sorted out on this list, and then the technology options can be analyzed. All I meant in the previous post is that we have workable technology right now, and so surely we should use it until something better comes along.
A few thoughts.
First, we should not ignore the strategy where SqueakMap is a place to find stuff about the *whole* squeak community, while Universes is used to organize the development of sets of packages. It would be much like FreshMeat versus APT in the Unix world. Ideally, all these tools (including SqueakSource and SqueakPeople) would communicate with each other to try and reduce the clutter that developers deal with.
Also, I am not sure how compatible it is to have a server that knows everything, but a package-set tool which wants to allow private local servers. These seem like goals which will be hard to solve with a single tool. Although, it sounds like you are giving it a go, Goran. If it works, then that's great!
I think we should keep in mind that Universes does address a lot of our needs, even though it does not have room (that I can figure out) to include a registry for the entire Squeak project. This reemphasizes, I think, the idea that maybe there should be two separate tools.
Finally, even if the individual programs are different, it could well be that SqueakMap becomes a project that includes two different kinds of tools in it. That's a wonderful result for me. I always have a large pile of interesting computer projects to work on, and thus I'm always happy for an excuse to set one aside or pass it on to someone else. I have been pushing this universes stuff because it seemed that people could not grok it without having a prototype to play with.
Avi, I agree that it makes sense to have some kind of public registry of universes. I wish Debian had that, but the powers that be don't seem to emphasize that there are other Debian packages in the world other than those in the official channels.
-Lex
Hi guys!
"Lex Spoon" lex@cc.gatech.edu wrote:
I don't have a specific proposal on what to do about SqueakMap and Universes, but my meta-response is: we should use whatever works for the goals we want to solve. I'm hoping the goals can be sorted out on this list, and then the technology options can be analyzed. All I meant in the previous post is that we have workable technology right now, and so surely we should use it until something better comes along.
I agree. So I don't mind people using Universes - in fact, I applaud the project and the effort. I only get nervous when I see the overlaps, so that is what I want to solve somehow. :)
And don't get me wrong - I don't mean to be "turfing" - I mean that I see people doing double work - both on the development side (you and me) but mainly on the user side.
A few thoughts.
First, we should not ignore the strategy where SqueakMap is a place to find stuff about the *whole* squeak community, while Universes is used to organize the development of sets of packages. It would be much like FreshMeat versus APT in the Unix world. Ideally, all these tools (including SqueakSource and SqueakPeople) would communicate with each other to try and reduce the clutter that developers deal with.
I agree, even though SM is a bit more than freshmeat today - it does download, install and maintain a cache too. But those things we could move out into a separate part, typically perhaps merged with Universes, or something. (sound effect of mind churning)
Also, I am not sure how compatible it is to have a server that knows everything, but a package-set tool which wants to allow private local servers. These seem like goals which will be hard to solve with a single tool. Although, it sounds like you are giving it a go, Goran. If it works, then that's great!
I think it can work - but I also think that there will always be room for a Universe approach in the whole scheme of it all. For example, if mixins turn out to be too troublesome for SM, then perhaps we can focus on having them on the "Universe level". Or whatever. So I agree, the different goals do give us a slightly different set of restrictions to work within.
I think we should keep in mind that Universes does address a lot of our needs, even though it does not have room (that I can figure out) to include a registry for the entire Squeak project. This reemphasizes, I think, the idea that maybe there should be two separate tools.
I think so too, I have "yet another plan" below. :)
Finally, even if the individual programs are different, it could well be that SqueakMap becomes a project that includes two different kinds of tools in it. That's a wonderful result for me. I always have a large pile of interesting computer projects to work on, and thus I'm always happy for an excuse to set one aside or pass it on to someone else. I have been pushing this universes stuff because it seemed that people could not grok it without having a prototype to play with.
This sounds interesting, I would love to merge it somehow with SM and below is a draft plan for that. I would only take it over if you would like me to (and anyone else stepping up for the task, see below).
Avi, I agree that it makes sense to have some kind of public registry of universes. I wish Debian had that, but the powers that be don't seem to emphasize that there are other Debian packages in the world other than those in the official channels.
Ok, what about this plan then:
1. We write a little announcement of our intentions to show the Squeak community that we mean business when it comes to combining these two tools in the best way we can see, and that I intend to make it happen (giving you room to hand it over to me or anyone else helping me). I think people want to hear a stated intention, whatever comes out of it.
2. We start by adapting SM so that it is Universe-aware in the ways I have described. That would be a first step and I will read through Universes in detail to see in what other ways we could do "first step integration". The end goal here is: - You can register Universes on SM and of course "use" them with SMLoader. This shouldn't be far away in the future at all.
3. We ask yet again for the hundredth time :) on squeak-dev if there are people interested in co-developing SM/Universes with me/us. Hopefully one or two people come out of the woodwork.
4. I read through the Universes code once more and I write an article describing how I would like to integrate it with SM while still keeping all its main features intact. That way you (or anyone else) can scream bloody murder if it sounds like I plan to do something dumb :).
5. If the article is met with agreement then I (together with anyone that have stepped up) take Universes and merge it with SM so that we end up with one or more packages working in unison.
After all our discussions and also after having seen how stuff works in Lunar Linux (they have a single Universe one could say) I think that the Universe model is a great way for preparing well controlled "managed" sets of packages. But it does need an effort - but I think that effort *could* be mustered - especially *in combination* with my mechanism for dependencies. This last part is in fact a realization I have come to after reading your Swiki pages - if we had my dependencies working, then that would work as a great "enabler" for building Universes.
Or in other words - my dependencies are "general" in that they are "context free". They try to describe the needs of a specific package release without a context, and they also are based on lots of people giving lots of input together. So it can be seen as a knowledge base of dependency information.
Then, using that knowledge base it seems that building Universes could be a much more pleasant experience. A Universe is in other words a separate artifact - with a maintainer/co-maintainer etc. That is a very distinct difference from my "pool of dependency information", just like you have noted here and there when discussing policies etc. So you know this of course.
Anyway, enough rambling - I think both our efforts should be available, and I think integration first and merging second is one way to go. If this sounds agreeable, and if Avi of course agrees :) - then I am offering my time to make it happen.
-Lex
regards, Göran
On Fri, 11 Mar 2005 08:20:29 +0100, goran.krampe@bluefish.se goran.krampe@bluefish.se wrote:
Anyway, enough rambling - I think both our efforts should be available, and I think integration first and merging second is one way to go. If this sounds agreeable, and if Avi of course agrees :) - then I am offering my time to make it happen.
I'm not sure if you're waiting for my agreement, but: go for it :). The only thing I might suggest (and feel free to ignore me) is that when you write your article about integrating SM and Universes, you post it here first so we can discuss it more intensely and make any needed revisions without bothering everyone else.
Avi
On Fri, 11 Mar 2005 08:20:29 +0100, goran.krampe@bluefish.se goran.krampe@bluefish.se wrote:
- We start by adapting SM so that it is Universe-aware in the ways I
have described. That would be a first step and I will read through Universes in detail to see in what other ways we could do "first step integration". The end goal here is: - You can register Universes on SM and of course "use" them with SMLoader. This shouldn't be far away in the future at all.
One nice thing here, for resources is general, would be to have them be dependent on an SM package (in a simple way, no need for the full dependency scheme). That is, when I try to load a Universes resource, it will first load the Universes package from SM so that the image knows how to handle it.
Avi
packages@lists.squeakfoundation.org