🚀 go-pugleaf

In article <LOWRY.92Oct6120218@rotor.watson.ibm.com>, lowry@watson.ibm.com (Andy Lowry) writes:
 
|>                                ... sentence deleted.  To me, C-S just
|> means that there's an entity called a "server" that is willing to take
|> requests from other entities called "clients" and perform work on
|> behalf of those requesting clients.  The problem with C-S is that the
|> distinction of who's doing work for whom isn't always very clear.  And

I agree. This misleading naming problem is also present in other areas. For 
example, in knowledge representation the terms catagory and instance, when
applied to concepts, appear to label absolutes. However, catagories can also
be instances - of "catagories of catagories". The same problem is carried over
to object oriented terminologies. 

The solution I like best is to make the relationship between the 
entities/objects/things the focus of the terminology, and label the entities 
with respect to the relationship. Hopefully, the label for the entities then 
carries the notion of "In relation to..." instead of "This is a...". For (an 
unimaginative) example, in the client-server case you label the relationship 
with the word reshnica, the "invoker" is called a resh, and the 
"invokee" is called a nica. When one entity is acting as a "user of services" 
in a reshnica relationship it is called a res, and when an entity is acting as 
a "supplier of a service" in a reshnica relationship it is called an nic. The
entity (resh or nica) that is acting as a res is not fixed during the life
of the relationship.

|> the problem with the typical software technology you see to support
|> C-S style computing is that it's typically made fairly easy (but not
|> nearly easy enough) to play the role of client, but much more
|> difficult to play the role of server.  There's an asymmetry in the
|> model, and there's an asymmetry in the implementations.  There appears
|> to be a view (I've heard it enunciated several times) that servers are
|> rare, and therefore it's not important to make them easy to create.
|> The notion seems to be that you create a distributed environment by
|> designing a small set of "distributed services" and then make it
|> reasonably easy for programmers to write programs that will make use
|> of those services.  This is a very close-ended and inflexible view,
|> and it doesn't help me much when my application doesn't logically fit
|> the limited C-S model.

This asymetry is present in the knowledge representation and object oriented
terminologies also. However, advantage is gained from it through the use of
inheritance.

	- Ajeet.

-------------------------------------------------------------------------------
Ajeet Parhar                         internet : a.parhar@trl.oz.au
Telecom Australia Research Labs.     phone,fax: +61 3 253 6167, +61 3 253 6362
Switched Networks Branch             post     : PO Box 249, Clayton VIC
Network Services & Signaling Section            Australia 3168
-------------------------------------------------------------------------------