A Squeak Packaging Proposal

Hans-Martin Mosner hmm at heeg.de
Fri Aug 10 09:29:24 UTC 2001


ajh18 at cornell.edu wrote:
> Imagine connecting to another Squeak image and sending the #size message
> to one of its collection objects.  You would expect the normal #size
> response, but you have no guarantee.  But if you can say execute #size
> with respect to the Squeak3.1 package (and here is my Squeak3.1 package
> in case you don't have it) then you know what's being executed.
But that's not the Smalltalk way, simply put.
Smalltalk is all about messages being sent to objects, and objects being returned as results. As the sender of a message, you're not supposed to know much about the class or implementation version of the objects you interact with.
>  I know
> I'm getting away from object-oriented encapsulation, but I came up with
> this solution when trying to devise a way to write distributed programs.
>  This is a way of saying: if you claim to be an instance of class
> Collection then I expect you to respond to #size the way Collections do
> in the Squeak3.1 package.  In fact, no matter what your class is I
> expect you to respond the way your class defines in Squeak3.1 package.
> And if your class is not in Squeak3.1 then raise an exception.  Classes
> will have to have globally unique ids as well, so we know we're talking
> about the same class.
Better talk about interfaces. If you expect a remote object to respond to a certain set of messages in a way defined in some interface, then that's a good thing. For example, if you have an interface 'Dictionary' which defines the basic dictionary protocol, you should not be concerned whether an object adhering to that interface is using a single or multiple hash buckets, B*-Trees, a mapping to a relational database or psychic abilities to retrieve the objects you've put into it.
There might me something like a Quality-Of-Service mechanism which tells you whether data stored in this dictionary object will be persistent, how fast (relative to some standard) its insertion, deletion, lookup, enumeration operations are etc.
But this still says nothing about class implementation versions, which are (IMHO) completely irrelevant...
I see one specific case where you need to know which version of software you're looking at: When you know that some version has some bugs, and you want to refuse working with such a version. Since these bugs are presumably not part of the interface, and also not part of the planned Quality-Of-Service of the implementation, you need to know exactly which version you're dealing with...
> 
> I guess this is an attempt to make images look the same when sharing
> data, so they behave predictably, but at the same time allow them to be
> different.  Presumably, messages received from the outside will run in
> their own process in their own environment (the one requested of them),
> while the UI process (and other processes) will run in separate
> environments unaffected.

Sounds like quite a difficult goal, and one that probably won't work in reality with distributed systems. Look at the wwweb: I know it has some totally uncool aspects, but one of the better aspects is that clients and servers are able and willing to work with completely different and unknown versions of servers and clients, as long as some basic interface is adhered to. This is a distributed system that works (mostly).

Cheers,
Hans-Martin

PS: Great that you've been looking at SCAN! I appreciate the kind words, and fully understand that it does not solve the problem that you try to solve. As far as server-centric goes: I did envision it mostly as a system with only intermittent communication, making it suitable for peer-to-peer architectures as well as server-client architectures. However, communication in SCAN is always about versioned larger-scale entities such as packages. Remote message invocation is not its goal.




More information about the Squeak-dev mailing list