Marcus Denker wrote:
On Mar 21, 2010, at 12:29 AM, Lawson English wrote:
Hi Marcus, actually I'm pretty sure most everyone on the Squeak side agrees with you here. The real difference is that Squeak wants to take the approach that we *do* that last step;
Since when? for the last 12 years, this *never* happend.
Marcus
So why does everyone ignore TeaTime? I admit I don't understand the internals, but it obviously *looks* like it could be the basis of Nebraska (or any other P2P solution).
Can you point me to a real good publication about it? I mean, a *real* one?
Marcus
Nope. In fact, I was surprised to learn that Cobalt doesn't even use TeaTime and that the last version of Croquet that used it was around 0.3. Apparently network latency for reliable message sending of an entire 3D world was greater than expected, so it was tweaked almost out of existence, at least in its original form. I am often wrong about these things of course, so corrections are welcome. OTOH, even if its NOT suitable for message sending in Croquet/Cobalt, it seems intuitively obvious that it MIGHT still be viable for use in less demanding 2D P2P scenarios. At least, I'm hoping it will be, because honestly, SVN sucks and doesn't apply at all for some of the stuff I'm hoping to use squeak for: P2P backend for plugins in virtual world viewers to share collaborative projects, obects, physics and whatever else people can come up with. One could certainly make the case that smalltalk won''t be fast enough for the high end requirements of such use-cases, but as it stands now the infrastructure really isn't in place for testing even the lowest end (person to person collaboration without requiring a web host for clunky flash based-games and drawing apps). Imagine collaborative etoys or scrabble or whatever tunning on a prim in second life, well integrated into the SL 3D environment where the etoy is controlling a 3D environment that is used by about 1 million people per month. As it stands, I can use squeak to POST messages to individual objects in Second Life and control all of their programmable behavior via a seaside-rendered GUI in a HUD object. My intent is to bypass http and directly use the Second Life media plugin to render a Morphic widow or squeak desktop onto that HUD without the overhead of SVN or http or html and and thereby create the beginnings of a squeak plugin to SL. As an aside, while people debated the utility of making it easier to embed squeak in games and such, the SL scripting team that has been working over the past 4 years to replace the Linden Scripting Langage with the mono CLR and allow C#/etc programming of SL objects, considered using Squeak as the basis for scripting the open source Second Life viewer, and rejected it because they didn't think it a viable way to go for various reasons, all of which have been raised at one point or another in the debate about embedding squeak in general. They're now planing on using mono as the basis of viewer scripting... Oh well, opportunities lost.. Lawson