So the question has come up yet again with my project as to why there is any reason to use Cobalt/Croquet instead of something with a bigger community that uses a more common programming language, such as Wonderland. We are committed to using an open source stack.
Instead of trying to come up with an argument on my own, I'd like to solicit the community's help. Why should we stick with Cobalt/Croquet? We are at a very early stage in development. Really just prototyping. So it would not be a monumental shift if we switched now.
Here is one: Cobalt/Croquet is green :) One reason is that when you rely on servers for the support of basic interactivity between participants of virtual worlds, then the deployment/support costs of any widespread (ubiquitous) use of such environments will require vary large investments in server infrastructures that dwarf our present investments in support of the web. Someone has to eventually pay for the machines and for the power to run and cool them. If you develop global scale metaverses with dependencies on servers (for basic collaboration between people), then you will drastically increase the costs to schools (already taxed) and make the power of collaboration only available to those who can pay. also check out: http://jlombardi.blogspot.com/2008/02/server-dilemma.html for more on what a global scale metaverse might invoke.
On Apr 3, 2008, at 10:37 AM, Matthew Schmidt wrote:
> So the question has come up yet again with my project as to why > there is any reason to use Cobalt/Croquet instead of something with > a bigger community that uses a more common programming language, > such as Wonderland. We are committed to using an open source stack.
> Instead of trying to come up with an argument on my own, I'd like to > solicit the community's help. Why should we stick with Cobalt/ > Croquet? We are at a very early stage in development. Really just > prototyping. So it would not be a monumental shift if we switched now.
------------------------------- Julian Lombardi, Ph.D. Assistant Vice President Duke University Office of Information Technology 334 Blackwell Street, Suite 1107 Durham, North Carolina 27701 USA +1.919.323.5016
Thanks Julian. I'm aware of the server dilemma. Unfortunately, I don't think the decision makers are going to see that as a compelling argument. I've used the same argument against using Second Life and they are frankly unconcerned. Servers? We don't pay for those. University students pay for them with their computing fees. *sigh*
I am only vaguely familiar with the Wonderland offering. I've kicked the tires a few times. I haven't done any "real" work with it. So I'm not in a position to compare or contrast Cobalt/Croquet with Wonderland. I'm hoping that someone can give me some key arguments about the differences between the two that go beyond P2P & client-server differences.
That's a great question. Above all our Croquet related efforts, the message about how we're different might be most important.
Until we can demonstrated it more fully, perhaps using analogies is best for explaining such differences. Note, many of the possibilities I described are facilitate by the architecture of Croquet, not necessarily already implemented in it's current version (like the exchanging of program behavior through sharing source code). Also, I've not tried Wonderland, so some of my comparisons and assumptions might be inaccurate and I welcome anyone to correct me.
Smalltalk is like the modeling clay of computer languages. You can easily make a change anytime and anywhere and at several places at the same time. But, it's easy for anyone to bump it and mar it. Other languages are like sculpting a stone sculpture. You can make only the changes that a chisel/tool can make and only one place at a time. The changes are slow and mistakes are hard to fix. But, it's also hard for anyone just touching it to mar it. The 3D part is like dressing the sculpture. It's easy to change clothes and accessories but the clothes have to fit the stone sculpture. If you want to try different sized clothes, it's easier to change the whole sculpture with the clay sculpture. You can chop up the stone sculpture into modules, but now you have a lot of separate piece to keep track of and make sure the person dressing the sculpture can keep track of the pieces as they change the clothes too. If you pile on too many clothes, the weight of the clothes may overload and bend the clay sculpture against our will, while the stone sculpture can hold a tremendous amount of clothes (as long as they are all the proper size for each layer). Note, we can bake the clay sculpture to be very close to being as strong as the stone one, but we lose the flexibility after that for the dressers, but we can make many of them rather quickly and bake them at different sizes.
It is easier to hand a blob of clay to a friend and have them start modeling right away, wherever they're at. One can hand their friend a stone and then a chisel but you'll have to train them, fix their mistakes, move to a safer area away from others, and they risk cutting themselves. If one has a 1,000 friends, it's a bit easier to hand out a 1,000 pieces of clay than 1,000 stones, chisels, training time, etc. It is easier to attach everyone's separate clay sculpture together into one sculpture, but it might not look like what everyone had in mind and may require extra adjustments. It is quicker to assemble everyone's separate stone sculptures together into a united sculpture if it is planed in exact detail from the beginning and everyone sticks to the plan, which rarely happens and the subsequent adjustments are harder to make in the stone.
Take Sun's Wonderland for an example now. Java may support many open source projects and its specification may be open to view. But, it has been very hard to ask Sun to change the Java language to meet modern needs. Java requires lots of extra tools to keep track of its pieces. Even if you can change the Wonderland code and change the Java language, who is willing to change all the servers to meet your specific change request? The culture and structure is to write a few times, read mostly, and get it right the first time because IT administrators and or local hosted server users don't like to change server software and take down access to the service while they are doing so. It affects too many people.
Smalltalk lets you create and share the content but the behavior, the code, can be shared as easily as the content. Croquet will be like a "live-running-software-wiki" where you can change eachother's world behavior while you're in world as easily as you can share a text document or edit a wiki, with a security structure in place like a wiki's pages or file uploads. Few, if any, server changes would need to be done by server admins.
Second Life and Wonderland have gradually added new media formats, in-world audio, in-world video, etc. But these media are like strangers in the 3D model world, requiring version changes and a new download of the client and server software as they are added. There is no "non-linear video editing" in the 3D worlds for example. Can you edit the sound and store it by manipulating 3D objects? Text editing in SL's shared experienced 3D space is almost impossible. Usually text must be converted to graphics or only edited in the 2D heads-up display (HUD). Can you write a 2D drawing program that exists in the shared 3D world of SL? 2D graphics is not a native media format in these 3D worlds.
Because everything is composed of "living objects" in Smalltalk, these artificial barriers are almost eliminated. One will be able to edit text or animat 2D graphics in a 3D world as easily as one does in a 2D world. Text, sound, and 3D objects can be attached to each other, while the system is running, in novel and, as yet, unimagined ways. New media yet to be invented will be just as easily handled w/o having to rewrite the entire UI to accommodate it with a "wait for the next version to be released to the open source community". Once someone accomplishes the import of the new media in one Croquet session, they should be able to immediately share the code for it with any other Croquet node that needs to import/manipulate that media.
This vision does require that everyone be willing to edit code as easily as they edit their blog or Facebook site. But that can also be delegated by a "trusted friend network". The PC computer became much more popular when almost anyone could create a program with Visual Basic and share it with anyone else. Before then, the commercial software was just not that interesting. With the advent of the PC and Visual Basic, every niche community could make their personal computer a tool for their specialty. Not so with the midrange or mainframe computer. Many novel ideas could be explored, broadly shared, and either thrown away or kept with a PC, but not a server.
Compare creating a website with a website editing software vs. a wiki. They both publish information in text and pictures to a web server, but one is more dynamic, interactive, easier to fix small mistakes frequently, easier to share the load of creating a single page among others. The other may allow one to be more accurate and precise control over the content, but adds several stages to go through to accomplish it. You have local storage of your copy and few people see that copy. You edit it privately then post a mostly finished product to the server if you have enough authority. Fixes require you to copy the page back down if someone else edited it and repeat.
When you say you want to use an "open source stack" the word stack implies all the levels one must install and maintain and which many may not be able to extend all the levels even if they are open source. Take the LAMP stack for an example. Would your team want to edit the Linux code? the Apache code? the MySQL code? the syntax of the PHP or PERL language? You can only really edit the configuration files and even those have different rules for every level in the stack. In Smalltalk, the stack is just one single layer, all editable while it is running... data storage format and technique, web server, OS type functions can easily be edited and even the syntax of Smalltalk can be molded into mini "domain specific languages" if needed because of the built-in compiler/interpreter.
3D environments facilitate a major trend. How we communicate and learn is rapidly changing and accelerating the rate of change as well. Croquet is a platform which can more quickly adjust to those changes than any other in my opinion.
I've put a comment a the end of each line describing how Croquet facilitates each trend.
* * From consuming to producing* - Even the casual person visiting the 3D world can edit the world's code to produce something new. * * From authority to transparency* - Everyone can see the code while they are running it. * * From the expert to the facilitator* - Teams of people can help each other in Croquet to change the application, especially at the moment it is most needed. You don't have to send a change request to the developers and hope they fix it. They can also communicate in more ways than a pre-made service could provide. * * From the lecture to the hallway* - Croquet is portable, w/o having to be always online. A two person notebook-to-notebook 3D network will be just as easy in Croquet as linking to a university 3D library of worlds. One's personal world is one's hallway for meeting others. * * From "access to information" to "access to people"* - One can find the initials of the code developers in Croquet to ask why an application works in a certain way. In Croquet, one can establish one's own criteria of what constitutes the group and how much attention is required to maintain participation in the group. * * From "learning about" to "learning to be"* - The flexibility in Croquet allows world creators to create environments that more accurately reflect/simulate what we are most concerned about. The simulation is not just a 3D movie about the subject material with extra buttons, it becomes the 3D control panel to manipulate and do something about the subject material. One learns by doing. Hence, one can practice at being a subject mater expert by practicing the same skills and manipulating similar object. * * From passive to passionate learning* - This can be accomplished by transitioning to the 3D environments in general. * * From presentation to participation* - This can be accomplished by transitioning to the 3D environments in general. * * From publication to conversation* - Croquet lets the
...
Darius, thanks so much for the very thoughtful and comprehensive response. This is exactly what I was hoping for.
I will respond to your points at a later date... I'm swimming in dissertation stuff right now... but wanted to ping you with a huge THANK YOU now. Your input is much appreciated.
On Tue, Apr 8, 2008 at 1:50 PM, Darius Clarke <socin...@gmail.com> wrote: > Hi Matt,
> That's a great question. Above all our Croquet related efforts, the > message about how we're different might be most important.
> Until we can demonstrated it more fully, perhaps using analogies is best > for explaining such differences. Note, many of the possibilities I described > are facilitate by the architecture of Croquet, not necessarily already > implemented in it's current version (like the exchanging of program behavior > through sharing source code). Also, I've not tried Wonderland, so some of my > comparisons and assumptions might be inaccurate and I welcome anyone to > correct me.
> Smalltalk is like the modeling clay of computer languages. You can easily > make a change anytime and anywhere and at several places at the same time. > But, it's easy for anyone to bump it and mar it. Other languages are like > sculpting a stone sculpture. You can make only the changes that a > chisel/tool can make and only one place at a time. The changes are slow and > mistakes are hard to fix. But, it's also hard for anyone just touching it to > mar it. The 3D part is like dressing the sculpture. It's easy to change > clothes and accessories but the clothes have to fit the stone sculpture. If > you want to try different sized clothes, it's easier to change the whole > sculpture with the clay sculpture. You can chop up the stone sculpture into > modules, but now you have a lot of separate piece to keep track of and make > sure the person dressing the sculpture can keep track of the pieces as they > change the clothes too. If you pile on too many clothes, the weight of the > clothes may overload and bend the clay sculpture against our will, while the > stone sculpture can hold a tremendous amount of clothes (as long as they are > all the proper size for each layer). Note, we can bake the clay sculpture to > be very close to being as strong as the stone one, but we lose the > flexibility after that for the dressers, but we can make many of them rather > quickly and bake them at different sizes.
> It is easier to hand a blob of clay to a friend and have them start > modeling right away, wherever they're at. One can hand their friend a stone > and then a chisel but you'll have to train them, fix their mistakes, move to > a safer area away from others, and they risk cutting themselves. If one has > a 1,000 friends, it's a bit easier to hand out a 1,000 pieces of clay than > 1,000 stones, chisels, training time, etc. It is easier to attach everyone's > separate clay sculpture together into one sculpture, but it might not look > like what everyone had in mind and may require extra adjustments. It is > quicker to assemble everyone's separate stone sculptures together into a > united sculpture if it is planed in exact detail from the beginning and > everyone sticks to the plan, which rarely happens and the subsequent > adjustments are harder to make in the stone.
> Take Sun's Wonderland for an example now. Java may support many open > source projects and its specification may be open to view. But, it has been > very hard to ask Sun to change the Java language to meet modern needs. Java > requires lots of extra tools to keep track of its pieces. Even if you can > change the Wonderland code and change the Java language, who is willing to > change all the servers to meet your specific change request? The culture and > structure is to write a few times, read mostly, and get it right the first > time because IT administrators and or local hosted server users don't like > to change server software and take down access to the service while they are > doing so. It affects too many people.
> Smalltalk lets you create and share the content but the behavior, the > code, can be shared as easily as the content. Croquet will be like a > "live-running-software-wiki" where you can change eachother's world behavior > while you're in world as easily as you can share a text document or edit a > wiki, with a security structure in place like a wiki's pages or file > uploads. Few, if any, server changes would need to be done by server admins.
> Second Life and Wonderland have gradually added new media formats, > in-world audio, in-world video, etc. But these media are like strangers in > the 3D model world, requiring version changes and a new download of the > client and server software as they are added. There is no "non-linear video > editing" in the 3D worlds for example. Can you edit the sound and store it > by manipulating 3D objects? Text editing in SL's shared experienced 3D space > is almost impossible. Usually text must be converted to graphics or only > edited in the 2D heads-up display (HUD). Can you write a 2D drawing program > that exists in the shared 3D world of SL? 2D graphics is not a native media > format in these 3D worlds.
> Because everything is composed of "living objects" in Smalltalk, these > artificial barriers are almost eliminated. One will be able to edit text or > animat 2D graphics in a 3D world as easily as one does in a 2D world. Text, > sound, and 3D objects can be attached to each other, while the system is > running, in novel and, as yet, unimagined ways. New media yet to be invented > will be just as easily handled w/o having to rewrite the entire UI to > accommodate it with a "wait for the next version to be released to the open > source community". Once someone accomplishes the import of the new media in > one Croquet session, they should be able to immediately share the code for > it with any other Croquet node that needs to import/manipulate that media.
> This vision does require that everyone be willing to edit code as easily > as they edit their blog or Facebook site. But that can also be delegated by > a "trusted friend network". The PC computer became much more popular when > almost anyone could create a program with Visual Basic and share it with > anyone else. Before then, the commercial software was just not that > interesting. With the advent of the PC and Visual Basic, every niche > community could make their personal computer a tool for their specialty. Not > so with the midrange or mainframe computer. Many novel ideas could be > explored, broadly shared, and either thrown away or kept with a PC, but not > a server.
> Compare creating a website with a website editing software vs. a wiki. > They both publish information in text and pictures to a web server, but one > is more dynamic, interactive, easier to fix small mistakes frequently, > easier to share the load of creating a single page among others. The other > may allow one to be more accurate and precise control over the content, but > adds several stages to go through to accomplish it. You have local storage > of your copy and few people see that copy. You edit it privately then post a > mostly finished product to the server if you have enough authority. Fixes > require you to copy the page back down if someone else edited it and repeat.
> When you say you want to use an "open source stack" the word stack implies > all the levels one must install and maintain and which many may not be able > to extend all the levels even if they are open source. Take the LAMP stack > for an example. Would your team want to edit the Linux code? the Apache > code? the MySQL code? the syntax of the PHP or PERL language? You can only > really edit the configuration files and even those have different rules for > every level in the stack. In Smalltalk, the stack is just one single layer, > all editable while it is running... data storage format and technique, web > server, OS type functions can easily be edited and even the syntax of > Smalltalk can be molded into mini "domain specific languages" if needed > because of the built-in compiler/interpreter.
> 3D environments facilitate a major trend. How we communicate and learn is > rapidly changing and accelerating the rate of change as well. > Croquet is a platform which can more quickly adjust to those changes than > any other in my opinion.
> I've put a comment a the end of each line describing how Croquet > facilitates each trend.
> * * From consuming to producing* - Even the casual person visiting the 3D > world can edit the world's code to produce something new. > * * From authority to transparency* - Everyone can see the code while they > are running it. > * * From the expert to the facilitator* - Teams of people can help each > other in Croquet to change the application, especially at the moment it is > most needed. You don't have to send a change request to the developers and > hope they fix it. They can also communicate in more ways than a pre-made > service could provide. > * * From the lecture to the hallway* - Croquet is portable, w/o having to > be always online. A two person notebook-to-notebook 3D network will be just > as easy in Croquet as linking to a university 3D library of worlds. One's > personal world is one's hallway for meeting others. > * * From "access to information" to "access to people"* - One can find the > initials of the code developers in Croquet to ask why an application works > in a certain way. In Croquet, one can establish one's own criteria of what > constitutes the group and how much attention is required to maintain > participation in the group. > * * From "learning about" to "learning to be"* - The flexibility in > Croquet allows world creators to create environments that more
> Darius, thanks so much for the very thoughtful and comprehensive response. > This is exactly what I was hoping for.
> I will respond to your points at a later date... I'm swimming in > dissertation stuff right now... but wanted to ping you with a huge THANK YOU > now. Your input is much appreciated.
> Cheers,
> -Matt
> On Tue, Apr 8, 2008 at 1:50 PM, Darius Clarke <socin...@gmail.com> wrote:
> > Hi Matt,
> > That's a great question. Above all our Croquet related efforts, the > > message about how we're different might be most important.
> > Until we can demonstrated it more fully, perhaps using analogies is best > > for explaining such differences. Note, many of the possibilities I described > > are facilitate by the architecture of Croquet, not necessarily already > > implemented in it's current version (like the exchanging of program behavior > > through sharing source code). Also, I've not tried Wonderland, so some of my > > comparisons and assumptions might be inaccurate and I welcome anyone to > > correct me.
> > Smalltalk is like the modeling clay of computer languages. You can > > easily make a change anytime and anywhere and at several places at the same > > time. But, it's easy for anyone to bump it and mar it. Other languages are > > like sculpting a stone sculpture. You can make only the changes that a > > chisel/tool can make and only one place at a time. The changes are slow and > > mistakes are hard to fix. But, it's also hard for anyone just touching it to > > mar it. The 3D part is like dressing the sculpture. It's easy to change > > clothes and accessories but the clothes have to fit the stone sculpture. If > > you want to try different sized clothes, it's easier to change the whole > > sculpture with the clay sculpture. You can chop up the stone sculpture into > > modules, but now you have a lot of separate piece to keep track of and make > > sure the person dressing the sculpture can keep track of the pieces as they > > change the clothes too. If you pile on too many clothes, the weight of the > > clothes may overload and bend the clay sculpture against our will, while the > > stone sculpture can hold a tremendous amount of clothes (as long as they are > > all the proper size for each layer). Note, we can bake the clay sculpture to > > be very close to being as strong as the stone one, but we lose the > > flexibility after that for the dressers, but we can make many of them rather > > quickly and bake them at different sizes.
> > It is easier to hand a blob of clay to a friend and have them start > > modeling right away, wherever they're at. One can hand their friend a stone > > and then a chisel but you'll have to train them, fix their mistakes, move to > > a safer area away from others, and they risk cutting themselves. If one has > > a 1,000 friends, it's a bit easier to hand out a 1,000 pieces of clay than > > 1,000 stones, chisels, training time, etc. It is easier to attach everyone's > > separate clay sculpture together into one sculpture, but it might not look > > like what everyone had in mind and may require extra adjustments. It is > > quicker to assemble everyone's separate stone sculptures together into a > > united sculpture if it is planed in exact detail from the beginning and > > everyone sticks to the plan, which rarely happens and the subsequent > > adjustments are harder to make in the stone.
> > Take Sun's Wonderland for an example now. Java may support many open > > source projects and its specification may be open to view. But, it has been > > very hard to ask Sun to change the Java language to meet modern needs. Java > > requires lots of extra tools to keep track of its pieces. Even if you can > > change the Wonderland code and change the Java language, who is willing to > > change all the servers to meet your specific change request? The culture and > > structure is to write a few times, read mostly, and get it right the first > > time because IT administrators and or local hosted server users don't like > > to change server software and take down access to the service while they are > > doing so. It affects too many people.
> > Smalltalk lets you create and share the content but the behavior, the > > code, can be shared as easily as the content. Croquet will be like a > > "live-running-software-wiki" where you can change eachother's world behavior > > while you're in world as easily as you can share a text document or edit a > > wiki, with a security structure in place like a wiki's pages or file > > uploads. Few, if any, server changes would need to be done by server admins.
> > Second Life and Wonderland have gradually added new media formats, > > in-world audio, in-world video, etc. But these media are like strangers in > > the 3D model world, requiring version changes and a new download of the > > client and server software as they are added. There is no "non-linear video > > editing" in the 3D worlds for example. Can you edit the sound and store it > > by manipulating 3D objects? Text editing in SL's shared experienced 3D space > > is almost impossible. Usually text must be converted to graphics or only > > edited in the 2D heads-up display (HUD). Can you write a 2D drawing program > > that exists in the shared 3D world of SL? 2D graphics is not a native media > > format in these 3D worlds.
> > Because everything is composed of "living objects" in Smalltalk, these > > artificial barriers are almost eliminated. One will be able to edit text or > > animat 2D graphics in a 3D world as easily as one does in a 2D world. Text, > > sound, and 3D objects can be attached to each other, while the system is > > running, in novel and, as yet, unimagined ways. New media yet to be invented > > will be just as easily handled w/o having to rewrite the entire UI to > > accommodate it with a "wait for the next version to be released to the open > > source community". Once someone accomplishes the import of the new media in > > one Croquet session, they should be able to immediately share the code for > > it with any other Croquet node that needs to import/manipulate that media.
> > This vision does require that everyone be willing to edit code as easily > > as they edit their blog or Facebook site. But that can also be delegated by > > a "trusted friend network". The PC computer became much more popular when > > almost anyone could create a program with Visual Basic and share it with > > anyone else. Before then, the commercial software was just not that > > interesting. With the advent of the PC and Visual Basic, every niche > > community could make their personal computer a tool for their specialty. Not > > so with the midrange or mainframe computer. Many novel ideas could be > > explored, broadly shared, and either thrown away or kept with a PC, but not > > a server.
> > Compare creating a website with a website editing software vs. a wiki. > > They both publish information in text and pictures to a web server, but one > > is more dynamic, interactive, easier to fix small mistakes frequently, > > easier to share the load of creating a single page among others. The other > > may allow one to be more accurate and precise control over the content, but > > adds several stages to go through to accomplish it. You have local storage > > of your copy and few people see that copy. You edit it privately then post a > > mostly finished product to the server if you have enough authority. Fixes > > require you to copy the page back down if someone else edited it and repeat.
> > When you say you want to use an "open source stack" the word stack > > implies all the levels one must install and maintain and which many may not > > be able to extend all the levels even if they are open source. Take the LAMP > > stack for an example. Would your team want to edit the Linux code? the > > Apache code? the MySQL code? the syntax of the PHP or PERL language? You can > > only really edit the configuration files and even those have different rules > > for every level in the stack. In Smalltalk, the stack is just one single > > layer, all editable while it is running... data storage format and > > technique, web server, OS type functions can easily be edited and even the > > syntax of Smalltalk can be molded into mini "domain specific languages" if > > needed because of the built-in compiler/interpreter.
> > 3D environments facilitate a major trend. How we communicate and learn > > is rapidly changing and accelerating the rate of change as well. > > Croquet is a platform which can more quickly adjust to those changes > > than any other in my opinion.
> > I've put a comment a the end of each line describing how Croquet > > facilitates each trend.
> > * * From consuming to producing* - Even the casual person visiting the > > 3D world can edit the world's code to produce something new. > > * * From authority to transparency* - Everyone can see the code while > > they are running it. > > * * From the expert to the facilitator* - Teams of people can help each > > other in Croquet to change the application, especially at the moment it is > > most needed. You don't have to send a change request to
