I was fooling around and noticed that Nebraska isn't in the Pharo RC image. Is it compatible at all with pharo, since it is based on Morphic? lawson
Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core. ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it. Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install. Cheers Mariano On Fri, Mar 19, 2010 at 10:41 PM, Lawson English <lenglish5@cox.net> wrote:
I was fooling around and noticed that Nebraska isn't in the Pharo RC image. Is it compatible at all with pharo, since it is based on Morphic?
lawson
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core.
ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it.
Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install.
Thanks, I did try to load it. I got various dependency issues which appeared to go back to: PluggableFileList>>morphicOpenLabel:in I found that in http://www.squeaksource.com/Pharo and attempted to load Morphic-MarcusDenker.551 but it had a nifty error that wasn't possible to read clearly because the error window was partly outside the boundries of the Phara desktop window and the interface froze. Although the system window was still dragable, none of the interior windows were. I eventually force-quit and tried again (3 times with same result). Lawson
On Mar 20, 2010, at 12:39 AM, Mariano Martinez Peck wrote:
Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core.
ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it.
Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install.
So of course this idea of "just load it" is very difficult (impossible) to realize if the software in question was just hacked and put code everywere in the base system.... I think after Nebraska was removed, we cleaned up the rendering of handmorph, for example. Nebraska complicates a far too complex Morphic system a bit. In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way. I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
+1 sad for genie ;( may be now with the new event handler if should be esaier to plug
Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core.
ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it.
Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install.
So of course this idea of "just load it" is very difficult (impossible) to realize if the software in question was just hacked and put code everywere in the base system.... I think after Nebraska was removed, we cleaned up the rendering of handmorph, for example. Nebraska complicates a far too complex Morphic system a bit.
In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way.
I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Would be really great. Stef On Mar 20, 2010, at 8:34 AM, Hilaire Fernandes wrote:
This is something I will be interested to look at, but not right now yet.
Hilaire
Stéphane Ducasse a écrit :
+1 sad for genie ;( may be now with the new event handler if should be esaier to plug
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Marcus Denker wrote:
On Mar 20, 2010, at 12:39 AM, Mariano Martinez Peck wrote:
Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core.
ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it.
Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install.
So of course this idea of "just load it" is very difficult (impossible) to realize if the software in question was just hacked and put code everywere in the base system.... I think after Nebraska was removed, we cleaned up the rendering of handmorph, for example. Nebraska complicates a far too complex Morphic system a bit.
In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way.
I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward.
Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free. The "Cobalt on a Prim" plugin should work pretty well, but its only going to be an oddity. Far more interesting will be to allow Nebraska-like/Cobalt-like sharing of applications without the extra overhead of VNC. My original plan was to somehow extract the TeaTime/Cobalt Island functionality and make it the networking layer between two instances of the Squeak-SL Plugin: Second Life <=> Squeak <=> Cobalt island (sans avatars and such) <=> Cobalt island <=> Squeak <=> Second Life Replacing "Cobalt" with "Nebraska" looked like a much simpler way to go (on paper) but obviously, it won't work with Pharo. Eventually, Cobalt will be remerged with Trunk so that it can work with the latest Squeak or Pharo. I guess I can fudge something for P2P that isn't quite so elegant in the meantime. OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo. Lawson
Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free.
not quite so :)
The "Cobalt on a Prim" plugin should work pretty well, but its only going to be an oddity. Far more interesting will be to allow Nebraska-like/Cobalt-like sharing of applications without the extra overhead of VNC. My original plan was to somehow extract the TeaTime/Cobalt Island functionality and make it the networking layer between two instances of the Squeak-SL Plugin:
Second Life <=> Squeak <=> Cobalt island (sans avatars and such) <=> Cobalt island <=> Squeak <=> Second Life
Replacing "Cobalt" with "Nebraska" looked like a much simpler way to go (on paper) but obviously, it won't work with Pharo. Eventually, Cobalt will be remerged with Trunk so that it can work with the latest Squeak or Pharo. I guess I can fudge something for P2P that isn't quite so elegant in the meantime.
Squeak certainly Pharo not necessary because we cleaned a lot and we will clean again. Now it depends on people energy.
OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo.
But Squeakers are pushing to get Cobalt on top of squeak not pharo so do not expect that it will work in pharo except if you make it happen (which we support). My point is not to be negative but to avoid giving false dreams. Stef
Stéphane Ducasse wrote:
Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free.
not quite so :)
The "Cobalt on a Prim" plugin should work pretty well, but its only going to be an oddity. Far more interesting will be to allow Nebraska-like/Cobalt-like sharing of applications without the extra overhead of VNC. My original plan was to somehow extract the TeaTime/Cobalt Island functionality and make it the networking layer between two instances of the Squeak-SL Plugin:
Second Life <=> Squeak <=> Cobalt island (sans avatars and such) <=> Cobalt island <=> Squeak <=> Second Life
Replacing "Cobalt" with "Nebraska" looked like a much simpler way to go (on paper) but obviously, it won't work with Pharo. Eventually, Cobalt will be remerged with Trunk so that it can work with the latest Squeak or Pharo. I guess I can fudge something for P2P that isn't quite so elegant in the meantime.
Squeak certainly Pharo not necessary because we cleaned a lot and we will clean again. Now it depends on people energy.
OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo.
But Squeakers are pushing to get Cobalt on top of squeak not pharo so do not expect that it will work in pharo except if you make it happen (which we support). My point is not to be negative but to avoid giving false dreams.
Stef
Well, Matt is working on the situation as we speak. I think the hope is that meging Cobalt to squeak trunk will make it MUCH easier to put it on top of Pharo, eventually. It would be nice if full TeaTime was available as its own separate module though. It may not be fast enough for 3D world events, but it might be fast enough for Nebraska P2P and smaller tasks, and I believe its considered perfect for message dispatching in multi-core SiliconSqueak. Lawson
On Mar 20, 2010, at 4:43 PM, Lawson English wrote:
Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free.
nothing is free ;-)
The "Cobalt on a Prim" plugin should work pretty well, but its only going to be an oddity. Far more interesting will be to allow Nebraska-like/Cobalt-like sharing of applications without the extra overhead of VNC. My original plan was to somehow extract the TeaTime/Cobalt Island functionality and make it the networking layer between two instances of the Squeak-SL Plugin:
Second Life <=> Squeak <=> Cobalt island (sans avatars and such) <=> Cobalt island <=> Squeak <=> Second Life
Replacing "Cobalt" with "Nebraska" looked like a much simpler way to go (on paper) but obviously, it won't work with Pharo. Eventually, Cobalt will be remerged with Trunk so that it can work with the latest Squeak or Pharo. I guess I can fudge something for P2P that isn't quite so elegant in the meantime.
Hmm... I am now expert on either of Nebraska or Croquet... but I used Nebraska over the internet (vs. local network) once: When Alan gave his keynote at CERN using my computer. We had to use a 1-bit black-and-white hacked version of nebraska and nevertheless Alan had a lag of some seconds (!!!) between what happend on my machine and what he saw via nebraska on his. Of course, the talk went *perfect* and we could have sold Squeak/Nebraska to the audience as *the* collaboration tool. But in practice, this was barely usable. (on the local network it works quite well, though).
OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo.
This is definitlly the way to go: have a good model for cross-image replication, than use that as the basis. Having two mechanisms that work completely differently is bound to make more problems than you want to deal with. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way.
I know that it's sad. And some people  I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward.
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; make the abstractions, do the work, extricate it from Morphic, clean it up, make it loadable. For Pharo's direction and needs, Nebraska has, understandably, not been not a priority. But why don't we move forward from always highlighting philosophical (or other) differences anyway? The interesting question is, can a single refactored-Nebraska work on both Pharo and Squeak? - Chris
Chris be sure that if somebody clean the core of morphic we are interested.
In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way.
I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward.
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; make the abstractions, do the work, extricate it from Morphic, clean it up, make it loadable.
For Pharo's direction and needs, Nebraska has, understandably, not been not a priority. But why don't we move forward from always highlighting philosophical (or other) differences anyway? The interesting question is, can a single refactored-Nebraska work on both Pharo and Squeak?
Now it can be a read pain without the right infrastructure. Stef
On Mar 20, 2010, at 10:41 PM, Chris Muller wrote:
In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way.
I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward.
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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Marcus Denker wrote:
On Mar 20, 2010, at 10:41 PM, Chris Muller wrote:
In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: to learn from them and than build abstractions in the base system to make these things implementable in a nice way.
I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are not used is important if we want to move forward.
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). Lawson
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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Burned out Sophie team members can talk to you about Tweak and TeaTime.... Don' t go there... Not that "a bit of effort" couldn't "fix it"
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
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 3/20/10 4:35 PM, Marcus Denker wrote:
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?
AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ). Michael
On 3/20/2010 4:43 PM, Michael Rueger wrote:
On 3/20/10 4:35 PM, Marcus Denker wrote:
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?
AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ).
Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications. That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250). Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here. As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides. Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward. BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works. Cheers, - Andreas
Good I like simple things. I'm really curious to learn it. So in a nutshell what is the idea of the synchronisation? How do do know which objects changed in an image? Stef On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote:
On 3/20/2010 4:43 PM, Michael Rueger wrote:
On 3/20/10 4:35 PM, Marcus Denker wrote:
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?
AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ).
Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications.
That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250).
Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here.
As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides.
Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works.
Cheers, - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Tea Time is a great implementation of how to synch two replicas of the same world of objects. Replication of Computation vs Replication of Data! Islands encapsulate a world of objects, that whenever send each other messages make the controller/router for that island to forward to all other replicated islands, the sent message (hence, computation vs data ( croquet vs Second Life ). And every island has a controller and a router with a message queue. Two replicas are consistent, because the same messages are "sent" in every replica. Every object ( TObject) tells its island that is has received a message. Fernando pd: I know a bit, because i've used Croquet for my master thesis. On Mar 30, 2010, at 10:44 AM, Stéphane Ducasse wrote:
Good I like simple things. I'm really curious to learn it. So in a nutshell what is the idea of the synchronisation? How do do know which objects changed in an image?
Stef
On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote:
On 3/20/2010 4:43 PM, Michael Rueger wrote:
On 3/20/10 4:35 PM, Marcus Denker wrote:
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?
AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ).
Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications.
That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250).
Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here.
As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides.
Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works.
Cheers, - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Intel engineer now speaking on "Designing Extensible and Scalable Virtual World Platforms" http://slurl.com/secondlife/IBM%20Business%20Center2/65/1/27 Part of virtual worlds workshop in Arkansas. http://vw.ddns.uark.edu/X10/X10--Schedule.html Lawson
On Mar 30, 2010, at 12:17 PM, Fernando olivero wrote:
Tea Time is a great implementation of how to synch two replicas of the same world of objects.
Replication of Computation vs Replication of Data!
Islands encapsulate a world of objects, that whenever send each other messages make the controller/router for that island to forward to all other replicated islands, the sent message (hence, computation vs data ( croquet vs Second Life ).
And every island has a controller and a router with a message queue.
Two replicas are consistent, because the same messages are "sent" in every replica.
what about if the messages arrives in different order ?
Every object ( TObject) tells its island that is has received a message.
Fernando
pd: I know a bit, because i've used Croquet for my master thesis.
On Mar 30, 2010, at 10:44 AM, Stéphane Ducasse wrote:
Good I like simple things. I'm really curious to learn it. So in a nutshell what is the idea of the synchronisation? How do do know which objects changed in an image?
Stef
On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote:
On 3/20/2010 4:43 PM, Michael Rueger wrote:
On 3/20/10 4:35 PM, Marcus Denker wrote:
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?
AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ).
Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications.
That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250).
Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here.
As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides.
Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works.
Cheers, - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Andreas Raab wrote:
On 3/20/2010 4:43 PM, Michael Rueger wrote:
On 3/20/10 4:35 PM, Marcus Denker wrote:
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?
AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ).
Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications. [...]
Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward.
BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works. I'm extremely interested in this kind of thing, since it helps hybridize virtual worlds with hopefully beneficial results for all concerned.
http://www.ietf.org/mail-archive/web/vwrap/current/msg00082.html Lawson
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
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.
I can imagine. When a smart guy opened Squeak in the past, his first reaction was to laugh or cry. (I do not say that against squeak - I got so burned by people looking at me in this strange way when I said that smalltalk was cool and they opened squeak in the past).
They're now planing on using mono as the basis of viewer scripting...
Obvious I would say.
Oh well, opportunities lost..
Yes and this is what we are trying to fix. Make a credible opensource smalltalk.
participants (10)
-
Andreas Raab -
Chris Muller -
Fernando olivero -
Hilaire Fernandes -
John M McIntosh -
Lawson English -
Marcus Denker -
Mariano Martinez Peck -
Michael Rueger -
Stéphane Ducasse