[Modules] finding the little buggers

Les Tyrrell tyrrell at canis.uiuc.edu
Fri Aug 17 15:25:03 UTC 2001


I would argue _slightly_ against what you are proposing here.  I do agree that 
as far as the user is concerned, they should not be presented with a bewildering 
variety of places to go looking for bits and pieces of code.  However, I would 
not want that to mean that there is literally only a single repository in 
existence- at least not in the sense of one server, sitting on one machine, for 
the entire planet.

HOWEVER.  I *DO* want it to feel like that is the case, in the sense that the 
user is presented the illusion of having rapid, unified access to everything 
ever written for Squeak ( or any other Smalltalk ) on the entire planet, sitting 
on their hard drive.

I think we could learn an awful lot from the way the Internet manages to remain 
operational even when large chunks of it are down.  And notice that we talk 
about it as "The Internet", not "That wild crazy collection of random bits and 
pieces of machines here and there".  That says something important, I think.

- les



Andrew P. Black wrote:
> At 16:43 -0700 2001.08.15, Dan Ingalls wrote:
> 
>> ...which would mean that if I get a Squeak release, whether delivered 
>> as a kernel and a pile of packages, or as a nicely partitioned image 
>> with everything loaded in, I have all sources right there in some 
>> local disk files.  I go to Kilauea, I'm still in total control.  IF I 
>> want to play Top Gun with all the other developers, I can change a 
>> preference and get hooked up with some fancy remote database and THEN 
>> I can get their changes, and share mine back.  'Fetch updates' would 
>> be a request to update packages that have changed recently
> 
> 
> Distributed systems can be fun -- at least, I've been having fun with 
> them for over 20 years now.  But that should not blind us to the fact 
> that sometimes centralized solutions are actually better, as well as 
> simpler and easier to understand.
> 
> "Fetch Updates" is one of the really neat things about Squeak.  Hey, 
> even Apple has copied it with their System Updates Control panel. Fetch 
> updates handles major version number changes, though ;-)
> 
> "Fetch Updates" works because there is one repository (OK, one and a 
> mirror) that has the updates.  Let's build on this idea.  How about a 
> single repository for _all_ Squeak Packages.
> 
> - The repository gives me a name when I want to create a new package. 
> This solves the package naming problem.
> 
> - The repository makes it possible, even easy, to search for message 
> name conflicts.  So, if I have a package that extends BlockContext with 
> a method #repeatForever, and can search and see if anyone else has 
> extended BlockContext with a method with the same name (a potential 
> source of problems), or has made the same extension (a potential way of 
> saving myself some work)
> 
> - The repository means that I'm never left wondering where I should look 
> for furble-unco-wibble_pre1.x86-k.bar.srpm; if it exists, it will be in 
> the repository
> 
> - The repository means that I can easily find the latest version of the 
> furble-unco-wibble package
> 
> - With a bit of documentation and search support, the repository means 
> that I can see if anyone else has already written a streaming multimedia 
> system before I start.   OK, we can do that now with the Swiki, 
> sometimes, or with  this list, if the author is still on it ...
> 
> - The repository is not ideal as a mechanism for supporting a Squeakend 
> or a Camp Smalltalk when a bunch of developers get together for a few 
> days, but don't have an Internet connection.  It does make it easy to 
> bring along a server with a copy of _everything_ to such a meeting, and 
> to re-synchronize with the online server when the meeting is over.
> 
> - The repository is really simple to explain to a novice.
> 
> - The repository is simple to implement.
> 
> Of course, it the Internet goes down unexpectedly, I'm unhappy.  But I 
> would be unhappy anyway, I suspect.
> 
>     Andrew
> 
> 






More information about the Squeak-dev mailing list