Spread (was RE: [DOCS] Maximum Squeak - accelerating Squeak a nd n amed primitives.)

Withers, Robert rwithers at quallaby.com
Mon Feb 10 20:45:33 UTC 2003



> From: Ned Konz [mailto:ned at bike-nomad.com]
> On Monday 10 February 2003 11:27 am, Withers, Robert wrote:
> 
> > I am now looking at multicast/broadcast key exchange mechanisms and
> > SecureSpread was recommended to me.  Isn't that hilarious?
> 
> Makes sense to me. But wouldn't my plugin work with Secure Spread? 
> Just recompile with that library (I guess there's more having to do 
> with authorization, etc., but it's a start).

Possible I think, but some of the token values have changed  (SSP_JOIN).
There may be a license issue.  I still like the idea of implementing in
squeak so we have control over the protocol implementation.  We do good
examples of application protocol support in squeak: the CVSSocket, IRC,
telnet, and several others.  I rather like my adoption of Ian's
LayeredProtocol, in SqueakElib, even though my use of it is incomplete at
the moment.  

Writing protocol support in squeak does provide us with some independence
from having to have the shared lib on the platform of choice, but any work
they do to negotiate protocol versions or bug fixes is now an extra
maintenance cost to us.

> > I think that I want to implement this in squeak again, but I will
> > probably use the SecureSpread algorithms.  I do want to look at
> > your SpreadPlugin. Did you manage to get a distributed object impl
> > working?
> 
> No, I was waiting for YAML. I was going to work from _why's Ruby 
> implementation, which uses RACC. Now that we have SqueakCC, perhaps I 
> can do this.

Yes, I was wondering about SqueakCC myself, in a serialization context.  I
quickly stopped thinking about it..too many other exciting avenues to
explore.  :)

cheers,
rob



More information about the Squeak-dev mailing list