[Squeakfoundation]A bit about SM1.1 and dependencies

[goran.hultgren at bluefish.se]

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> Hi Goran, everyone.
> 
> Since you mentioned it...
> 
> I know you have a paying job, which takes understandable precedence, and
> delays the SM1.1 release. I would ask that you please consider doing a
> work-split, that is, reprioritize the features, decide which ones have
> to be in then next release, formally delay the others, such that the
> next release is a as soon as possible.

Yes, I wil/am trying to do that. My writings doesn't really show that
perhaps - I often mix planned stuff with immediate stuff in order to get
the big picture a bit clearer.

> Obviously, what I'm really getting at, is that we really need very
> little to be able to build functional depedencies mechanisms. An SM
> release that does nothing else but that would be VERY valuable to the
> Squeak community. Just to remind those of us that aren't thinking about
> this all the time why:
> 
> 1. It would enable publishers of complex packages to split them, making
> the package more modular, and yet keep the ease of installation single
> packages enjoy.
> 2. It would enable a process to begin where people make up their
> favorite configurations, and share them. This would be a big step
> towards making distribution of images easier to democratize, and less a
> bottleneck.
> 
> AFAICT, the only additional mechanism required to support dependencies
> is package/card versioning. Links and resources would be nice to have,
> but they aren't stopping us from implementing dependencies.

Well, given my plan of us being able to register "package
configurations" associated with a package release *as* a Resource - it
is needed. And Links too of course - Resources of course need to be
linked to something.

But don't get scared by this - these two mechanisms are very simple and
I have that stuff more or less implemented including package releases.

Things I *am* waiting with:
- The ability to make modifications to the map in a distributed fashion.
- And thus also: The API for modifying the map.

And two more things I *do* want to include:
- A sensible cache instead of the braindead scheme right now. But this
is also simple.
- The new service architecture instead of the current "install or
download" choice.

Note that the package configurations and corresponding dependency engine
I have been blabbering about is *not* included here - that is meant to
come as an addon later. And anyone could start coding that up right now
I think.

> I know any changes in a release plan requires shifting some things
> around, but I think in this case it is quite worthwhile...
> 
> I understand that your time is still limited, I'd just like to "get"
> dependencies as soon as possible. It might help if we have some sort of
> initial release and can help test/debug. In this view, the incremental
> addition of prototypical services to SM 1.0 might be easier to handle
> than work on a non-production SM1.1.

Well, I am not sure what is the best way forward - I have SM1.1 on my
drive and it does have package releases, quite a lot of refactoring
done, links and resources in the model and the new service architecture
halfbaked. I have a sketch in my head for a better cache model, need to
whip through the web UIs so that we can register releases, resource etc
- but that is pretty easy coding.

Anyway, I will try to throw in a bunch of hours in this the coming week
- at least enough to post a developer snapshot so that anyone could help
me - if there is interest. My current fixed price job is pressing me
pretty hard. It will get easier in late feb, early march.

regards, Göran

PS. Whatever happened to those kernel images that Dan and Andreas spoke
about? I would really like to have a small headless network enabled
image for a little hack to my brother...