Hello, I've just joined this list but I've been following the posts for a while, along with the whitepapers and software on the VPRI site. I've also written http://en.wikipedia.org/wiki/COLA_(software_architecture) (and was given a much-appreciated thank-you from Ian Piumarta), but now that I've taught myself the basics of Smalltalk/COLA I'm looking for something useful to hack on to teach myself through doing.
I'm a student Physicist and Computer Scientist, and my current computing project is on "distributed" computing using Java's Remote Method Invocation system. This has given me an idea for something to extend the COLA system with, which I'll elaborate on below. The RMI system allows an object to be accessed over a network through the use of stub objects on each machine in a setup like the following: obj.method1() -> stub.method1() -> TCP -> stub.method1() -> obj.method1() So that calling method1 on the object obj on the left (on one machine) actually calls it on the object obj on the right (on a different machine), encapsulating the networking through the stub objects. This all works through Java interfaces, ensuring that the two objects and their stubs all have the same API. To me a much more elegant solution would be to use an Id style method lookup mechanism, then simply subclass/clone a VTable which performs its lookups over TCP (ie. doing the job of the stub objects). I'm researching how easy it would be to do such a thing in Sun's JVM, but all of my solutions are inelegant hacks to get around Java (as most of my Java programs are TBH). I'd like to implement this in COLA, firstly since I would like to see if this elegant way actually works, and also since I know there's been work on using TCP within COLA (in the examples). A couple of questions: Is this worth doing now, or waiting a bit? I've heard from Ian that the COLA implementation is getting a facelift? Also, are there any recommendations on where to begin with such a thing? Are the TCP examples robust enough to use or should they be rewritten? From a quick peruse it seems to have large chunks of OMeta cluttering the code, and from other messages it seems that COLA's OMeta is out-of-date. Also, on a slightly related topic, are there plans for restricting access to state in the COLA system, since from reading the ALBERT paper it seems like direct state access is a cause of some headaches. With state modified by messages (presumably in the/a VTable) it would turn the object system into an actor system, which is inherently concurrent. This, combined with transparent access to remote objects/actors, would make the COLA system parallel and distributed. I think such a thing is worth investigating, and having remote access to objects is a prerequisite I think I could take on. Regards, Chris Warburton _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
