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