Dependencies, Squeak Code Control [proposal,
long] (was: [TFNR][REPORT]Where are we?!)
Colin Putney
cputney at wiresong.ca
Tue Nov 18 21:57:15 UTC 2003
On Nov 18, 2003, at 12:29 PM, Peter van Rooijen wrote:
> Goran, Stephane, et.al.,
>
> I saw your discussion about code control: dependencies (module
> requirements), package configurations, bundles, packages, etc.
>
> I have some experience and have done some work in this area, and I
> thought
> it might be helpful to present a code control scheme that I feel could
> work
> well for Squeak. It's a design that is quite a bit lighter-weight than
> Envy
> or
> StORE, and much more powerful than simple class categories and
> variants of
> that. It requires no change to the way the image works with code, yet
> it
> provides versioning, dependency management, build control, and support
> for
> a distributed repository.
>
> I would be happy for this design to be used as a basis for discussion
> or
> implementation.
Not to be too undiplomatic, but I'm wary of going down that path. It's
not so much that I don't like the design as that I'm uncomfortable with
the approach. The past is littered with similar projects that failed,
despite the soundness of their design or the excellence of their
implementations.
The design you present is pretty comprehensive, and is strikingly
similar to the way John Sarkela described Team/V to me at OOPSLA. I
have no doubt it's capable of supporting all the features that users of
that and similar systems have come to expect. The problem is that it's
large and monolithic - a Big Design Up Front - that must be implemented
and deployed in one giant leap. The recent progress we've made in
package management and versioning has been because we took baby steps.
We built the simplest possible tools to solve the most basic problems
we face. We started using those tools and adapted our development and
social processes to them.
Now it's time to go back to the beginning and start a new iteration.
What problems need to be solved now? Here are the three problems I
think we should tackle next.
1) Package dependencies. If I'm loading a package that depends on
another package, I want SqueakMap to notice this and load that package
for me as well. There are lots of ways to do this, of course, but I
think Göran's plan is excellent. The only thing missing is code.
2) Version history queries. Monticello needs better facilities for
answering questions like "what is the history of this method?", "What's
the latest version of this package?", "What are the senders of this
message, now and in the past?" Avi and I are working on this now.
3) More explicit packaging in the image. We need to make the
development tools - browsers, message lists, change sorters and so on -
package aware. We also need to refactor parts of the kernel, compiler
etc, to make it easier to make it easier to load and unload packages
safely. The guys at SCG are probably the experts here, since Roel's
Notifications work is key to this, and they've already discovered the
hard way where the issues are in hacking on the SystemBrowser. Ned and
Daniel have also done some useful work in this area. Nevertheless, this
is probably the area that's the least "sorted out" in terms of how to
proceed.
What do people think about this? Are there any problems I've
overlooked? Reasons why these are non-issues?
Colin
More information about the Squeak-dev
mailing list
|