Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
goran.krampe@bluefish.se wrote:
Or putting it another way - making a competitor to SM or DVS would be in many ways counterproductive since these tools in some ways work their magic by turning into de facto standards for the community. Much better to cooperate on them. :-)
I disagree in general - alternative solutions to the problem DVS solves, for example, don't hurt the community, because their functionality is more important than the synergy of sharing the same format. This is because the different formats do not add significant issues, because SM makes hides them by abstracting the install option. So a "better DVS" (just an example) is a good thing.
SM specifically, OTOH, derives most of it's benefits from the network effect (everyone is putting his package in one place, and everyone looks for code in one place), and thus two incompatible catalogs would probably be worth less than just one, functionality almost not-withstanding. So SM competitors would be hard pressed to provide real value.
And that is btw one of the reasons I really want opinions on SM. Since a few important issues were reaised on the list recently I am in the process of writing down how SM1.1 will work on:
It's been a couple of months since the last time I said this, so I consider it borderline-polite-nagging ;-).
IMO, nothing matters as much as that you release something as soon as possible that supports package releases. - Details of distribution of the DB is unimportant. - UUIDs vs. names is unimportant. - Caching is unimportant.
Why? because releases in SM allow dependencies to be handled in various intelligent ways, which would save people like Stephan from inventing their own schemes that are non-scalable simply because versions are not supported. Such a release would let loose the next "avalanche" of progress in the package handling aspects of Squeak. Also, while 3.6 release is pretty far away, we do need to start seeing how we actually handle releases in and after it, and to do that we need SM 1.1.
So please do whatever you can to release asap, we need SM1.1 now! :-)
Daniel
Daniel Vainsencher danielv@netvision.net.il wrote:
goran.krampe@bluefish.se wrote:
Or putting it another way - making a competitor to SM or DVS would be in many ways counterproductive since these tools in some ways work their magic by turning into de facto standards for the community. Much better to cooperate on them. :-)
I disagree in general - alternative solutions to the problem DVS solves, for example, don't hurt the community, because their functionality is more important than the synergy of sharing the same format. This is
Well, I agree. Nevertheless, the more people that use one format the more incentive to make that a good format. But whatever.
because the different formats do not add significant issues, because SM
[SNIP]
And that is btw one of the reasons I really want opinions on SM. Since a few important issues were reaised on the list recently I am in the process of writing down how SM1.1 will work on:
It's been a couple of months since the last time I said this, so I consider it borderline-polite-nagging ;-).
It's ok, I know I have talked about SM1.1 for a long time and haven't delivered yet. I can't say anything else than that I am trying but that a small thing called "life" keeps me pretty busy. I do have more time now though than before.
IMO, nothing matters as much as that you release something as soon as possible that supports package releases.
- Details of distribution of the DB is unimportant.
- UUIDs vs. names is unimportant.
- Caching is unimportant.
Why? because releases in SM allow dependencies to be handled in various intelligent ways, which would save people like Stephan from inventing their own schemes that are non-scalable simply because versions are not supported. Such a release would let loose the next "avalanche" of progress in the package handling aspects of Squeak. Also, while 3.6 release is pretty far away, we do need to start seeing how we actually handle releases in and after it, and to do that we need SM 1.1.
So please do whatever you can to release asap, we need SM1.1 now! :-)
I know. I am not sure though that I agree with the three bullets above. The first one I agree with. The second one is... I agree, not *important* - but harder to change the longer we go. My current thought is to "prepare" a bit by some very small adjustments and simply keep doing things as they are. So I am keeping UUIDs for SM1.1 but preparing for 1.2. In other words - no effort lost on that issue at this point, don't worry.
Caching is not that unimportant because I think it is a key mechanism for the distribution of 3.6. I want people to be able to easily download a minimal/basic image and to be able to build "full" themselves. So I actually think PackageReleases (+ the little simple mechanism to add meta info to packages/releases which I call SMResources) and the cache are the key features of SM1.1. I will most probably only go for those - unless some very easy things pop up along the way that seem good.
But in general I agree with you Daniel. :-)
regards, Göran
Hi all,
Just a simple point about packages. I discussed a lot with Avi and I think that while DVS is a simple start the future is to have real package and not only hack around the categories. Avi agrees on that. I discussed recently also with joseph and he said that Ginsu is free (I should send him a license). What would be good is to have a group of people discussing/cooperating to create this asset. May be this is already in place (sorry for not knowing it).
So there is still a gap between having definitions in the image (like in Ginsu) and only definitions in the exchange files but having definitions is important. We should have a way to see in the file that we declare a new Class, Pool what ever. We could have then multiple run-times if people want and we could load code without installing it. So imagine what we could do.
Having support for real package in the image is not really difficult but the browser is so much a pain that it will hamper any move. Nathanael and alex for the traits and the classboxes had to fix, patch, this gory browser, Markus also for his ideas. What we are planning to do here is to build our own browser where they could plug what they need for their research. I will check what is the plan but it should be still in our current plans. First we want to fix the core (compiler, changes notification, classOrganization). However, this means that we could take into account that other entities such as packages could be used there too.
Stef
On Sun, 25 May 2003, Stephane Ducasse wrote:
Having support for real package in the image is not really difficult but the browser is so much a pain that it will hamper any move. Nathanael and alex for the traits and the classboxes had to fix, patch, this gory browser, Markus also for his ideas. What we are planning to do here is to build our own browser where they could plug what they need for their research. I will check what is the plan but it should be still in our current plans. First we want to fix the core (compiler, changes notification, classOrganization).
Yes, I think this is the most important. Once there is a clean Browser sitting on top of clean changes notification and clean class notification, it will be much much easier to do experiments with packages of all kinds.
Meanwhile I'm continuing to hack away at some 80% solutions. Most of the work I'm doing on Monticello doesn't really care how packages or even code declarations are specified, it's just concerned with the versioning aspects - so although I am providing a declarative package system of sorts, it would be possible to switch to something like Ginsu at a later point if that seemed worthwhile.
squeakfoundation@lists.squeakfoundation.org
-
Avi Bryant -
Daniel Vainsencher -
goran.krampe＠bluefish.se -
Stephane Ducasse