----- Original Message ----- From: Edmund Ronald eronald@rome.polytechnique.fr To: squeak-dev@lists.squeakfoundation.org Sent: Monday, October 29, 2001 4:42 AM Subject: Re: [ENH][Modules] Delta Modules [was: Another version]
I seem to have forgotten to unsubscribe and this thread caught my eye. Oh well. As a journo, my heart goes out not to developers but to users. So:
Among reasons for having modules two are obvious:
Facilitate distribution: Coders can release directly without reference to a central distributing authority. Users can shop around for the pieces they need.
Facilitate maintenance. Coders can amend their code without referring to a central maintaining authority. Users can upgrade modules incrementally during system life.
In practice, the two conflict. Users get caught in DLL hell. Microsoft are not entirely dumb, but they realised it too late because it is a scale effect. The redhat people noticed the issues in upgrading Linux and tried to fix them with the rpm database. It sold the distro, but ultimately didn't work, just pushed back the problem by about 2 years, and then scale effects caught up again, as soon as the number of sources for things increased. Nowadays, with all these systems, people do a few customisations, then throw away the fragments and re-install a whole new boxful of toys again. The reason for the frequent release of complete Linux systems, when Unix is inherently modular, has become the certification by the vendor of coherent behavior of the whole.
Certification leads to a whole mess of issues, but one thing I thought would be important ( years ago, before I realized it would be a Hard Problem ) would be to come up with ways of decoupling inter-module dependencies... that is, I didn't want modules to know about the specific existence of particualar other modules, but they could be allowed to know what they *expected* about the components in other modules- much like the way we do not require Classes to know explicitly about which classes implement the methods they are sending, but we do hold the *expectation* that the objects we are interacting with will understand the messages we are sending them.
I urge you, when analyzing this issue to look at the fundamental ways in which all known approaches have failed. Solving your module problem now for the existing handful of knowledgeable and sophisticated Squeak users/developers may not be the same as solving it for a distribution which has made it out of the lab into the wild.
This is why I really like the idea of supporting the ability to rapidly develop, test, and dispose of various approaches to modularization- basically, the "weak" modularity approach, where the existing tools remain unmodified ie, browsers and system dictionary are not changed ). I've been plinking away at Oasis for 5 years, and this has not been a straightforward process at all. Even now, though I believe that I really understand this problem a lot better than I did back then, I am not ready to jump up and say "this right here is absolutely IT- the Real McCoy, the Solution you've been looking for".
Fortunately, I'm no longer the only one ( or so it has seemed ) interested in this. There are some really good contributions coming out, and we can start comparing notes. These days I am building additional tools for Oasis ( a message tracer, actually a subset of another already existing tool in Oasis ), and looking at integrating ModSqueak, SCAN, and something of my own which is intended to deal with the same problems that Collage should have been good for solving. I'm also looking at what it would take to get Oasis out of VisualWorks- actually, there are big chunks of it that can be moved easily- the only hard part is redoing the active components, not an issue if one focuses initially only on inert components ( Oasis started out with components, and I still have them ). So, finally, after a really long time, I am hoping to start sharing some of the stuff I've learned building Oasis with the rest of the Squeak community.
- les