How different Croquet is from say netmeeting/Remote Desktop Sharing?
When everything could be shared between machines using RDS, what additional value does croquet brings in apart from Modelling and simulation environment. Do we have to restrict croquet for modelling and simulations and use the existing RDS solutions to colloborate with other non-croquet applications..Whats the business value in going for Croquet?
Thanks for any inputs...
In some ways, that is exactly what we are after - a replicated
simulation environment. The basis of this approach is that collaboration
between people is a persistent process, not a discrete event. Croquet
allows the user to create a replicated shared environment where there is
a guarantee that any objects and simulations in the environment are
identical for all the users of this space. The intent is to foster
collaboration using this replicated computation. What we want to do is
create a broadband communication channel that goes well beyond simply
text, voice, or even video - but allows the user to express and share
even complex ideas via the simulation.
We have a great interest in integrating existing media into Croquet, but
see this as an extension to the primary goal of fostering deep
> How different Croquet is from say netmeeting/Remote Desktop Sharing?
> When everything could be shared between machines using RDS, what additional value does croquet brings in apart from Modelling and simulation environment. Do we have to restrict croquet for modelling and simulations and use the existing RDS solutions to colloborate with other non-croquet applications..Whats the business value in going for Croquet?
> Thanks for any inputs...
On Jan 22, 2007, at 9:51 AM, David A Smith wrote:
> Hi Kiran,
> In some ways, that is exactly what we are after - a replicated
> simulation environment. The basis of this approach is that
> collaboration between people is a persistent process, not a
> discrete event. Croquet allows the user to create a replicated
> shared environment where there is a guarantee that any objects and
> simulations in the environment are identical for all the users of
> this space. The intent is to foster collaboration using this
> replicated computation. What we want to do is create a broadband
> communication channel that goes well beyond simply text, voice, or
> even video - but allows the user to express and share even complex
> ideas via the simulation.
Continuing this high-level explanation just one level of abstraction
down, there are several beneficial outcomes from this replicated
* The programming model (in which the system replicates external
messages for you and the math gives you the replicated state) is much
simpler than ad hoc state management by the programmer. Aside from
productivity, this can have a huge effect on correctness, and
therefore on project success. The effect is analogous to the benefits
of compiler-controlled stack management in what were once called high-
level languages, or the benefits of runtime-controlled memory
management in garbage-collected languages. By contrast, state-
management is the overwhelming majority of large-project programmer
activity today, and the cause of the majority of project failures.
* In its current form, the model requires centralized processing of
messages only to receive, timestamp, and distribute them. This is far
more efficient in terms of throughput than centralized computation
systems. Croquet can therefore potentially handle a lot more. Small
dedicated hardware router boxes are even possible. (Theoretically, it
may be possible to also be more efficient in terms of latency by
using a distributed router, but this remains to be determined.)
* The other two benefits makes it practical to include disparate
models within the system itself, including a model of each user. I
believe this provides a tremendous but hard to quantify benefit in
making applications individually far easier to use successfully,
allowing applications to be reused and recombined in ways not
intended by their original authors, and in using them better because
they are in a more complete social and technical context.
Now, the difference between theory and practice remains to be seen
here. Also, through extraordinarily careful programming, other
architectures can duplicate some of these benefits in special
circumstances. But over time and over multiple projects, it's hard to
compete with good math.
> We have a great interest in integrating existing media into
> Croquet, but see this as an extension to the primary goal of
> fostering deep collaboration.
I've been discussing some work with embedded apps, especially
including VNC. I want to emphasize that I see this as an expedient
escape to existing stuff that doesn't follow the Croquet model, and
that such escapes can interfere with maximizing all the above benefits.
> kiran wrote:
>> How different Croquet is from say netmeeting/Remote Desktop
>> Sharing? When everything could be shared between machines using
>> RDS, what additional value does croquet brings in apart from
>> Modelling and simulation environment. Do we have to restrict
>> croquet for modelling and simulations and use the existing RDS
>> solutions to colloborate with other non-croquet
>> applications..Whats the business value in going for Croquet?
>> Thanks for any inputs...
Perhaps the simplest answer, Kiran, is that Croquet is not intended to
compete with Microsoft Vista. If you want eye candy and the ability to
run ancient applications on ancient hardware in service of users who
spend their entire waking life filling out forms or editing documents
using Micrsoft products, just use Vista. It will make you happy
enough. Or if you don't like Vista, use the Linux distro that comes
closest to copying the functionality and approach of Vista and the
Microsoft producivity applications. :-)
> So colloboration with existing media is an extension to primary goal of facilitating simulation mechanism through replication environment.
> Going further, i understand that there is embedded application framework provided by Wisconsin libraries of Croquet. This is based on RFB/VNC protocol. But why does the programmer has to laboriously go through this mechanism to populate the islands(Non Croquet) inside Croquet, when he could as well do that directly through VNC channel independently. What additional advanatages one would gain by populating within Croquet.
> Infact why cant we complement Croquet with existing RDP based applications for remote sharing.
> Added to that, Croquet scalability beyond subnet/LAN/WAN..which is not yet tested/reliable for business applications..Added to that RDP is a better protocol compared to RFB for performance reasons beyond LAN...How do we bank upon them for enterprise applications network connectivity...
> Also there is a lot of graphic resoucrces needed..So how do we manage low end desktops..thats where RDS can pitch to mitigate the need for high end systems...thereby reducing the deployment costs...
> Appreciate your feedbacks to know better..Thanks
On Jan 23, 2007, at 10:53 PM, kiran wrote:
> Thanks so much for all your feedbacks..
> To list out the questions as requested by Howard..
> Here they are..
> 1. For legacy applications, why do we need to go through RFB
> channel in Croquet rather than doing it independently through RDP/VNC?
You don't. In two senses.
First, I'm not sure what you mean by an "RFB channel in Croquet" vs.
"independenty" through VNC. In the Croquet demo that uses it, RFB
and VNC are synonymous. As I've tried to convey, VNC/RFB windows in
Croquet are like a whole punched through the fabric of Croquet.
Behind each VNC/RFB window is a separate VNC/RFB client that makes
its own connection to a shared server. Each replicated instance -
that is, window X on my machine and the same window X on your machine
- is connecting to the same "shared session" on the VNC server. Thus
the collaboration between us through that window is independent of
Croquet. (Your input gestures do go through Croquet first, but we
don't really have to do that. In fact, in an earlier version
(Dormouse), we didn't. Maybe that's what you mean?)
Second, you don't have to use anything. The architects have released
a Software Developers' Kit, with which developers may build
applications, and containing several demonstrations of the
technology. The license lets you build whatever you want, including
commercial applications, and there are folks doing precisely that.
As we've been discussing, Croquet defines a rather unique computing
model with specific mathematical advantages for problems in
collaboration. The demos are primarily to illustrate that this model
works. It is not tuned. It is not packaged in a commercial
application. But it works.
An extraordinarily rare thing about the Croquet model is that it can
encapsulate various kinds of legacy applications without rewriting
them. There are several ways to do this, and they vary in the extent
to which they extend the benefits of the Croquet model to the legacy
application. There are examples of several of these in the SDK, but
no given example is necessarily going to meet any your requirements.
They're just starting points.
> 1(a) Assume that one requirement is the need to talk to some
> desktop application/Web based enterprise applications/SAP.
I usually find it more useful to know the business requirements
rather than technology conclusions. Specifying a conclusion as a
requirement doesn't usually give me enough information to evaluate
the inevitable engineering tradeoff decisions that arise.
> We dont want to write it allover again in Squeak. We would look at
> integrating them with Croquet environment. The approcah would be to
> develop TPortal to these application..and interacting with them
> through embedded application frameworks( Scamper/Wiscosin open
> source browsers like firefox) thereby populating them in Croquet
> environment. Is this the approach correct..
I can't say without knowing more about your application. I'm sorry
if I lost track and missed a description of what you're trying to
Clearly there's something drawing you. But if you're looking to just
replace something that you're already doing satisfactorily now, than
I can say with confidence that, in my opinion, you're doing the wrong
thing. You should be looking for something that nothing else can
accomplish, and so there is no comparison.
> If that above scenario is correct, what i am doing is to divert the
> colloboration through Croquet's RFB channel..what benefits do i get
> by doing so?
> 1(b) Is there any selective customization per user to see what he
> wants (not everything) in Croquet?
Yes. All of the first six papers at http://opencroquet.org/
about_croquet/papers.html describe this.
> Do we have to write login screen per TPortal?
I don't think I caught enough about your use case to answer.
> 2. How scalable is Croquet beyond LAN when compared to other
> existing RDS colloborations?
It depends on what you're trying to do. If you're just embedding RDS
or similar inside of Croquet, then you're ultimately going to be
bound by the RDS server.
It remains to be seen how many users can be supported by a single
Croquet router in a "pure" Croquet application. As I mentioned, the
router could even be a dedicated piece of hardware, but I don't know
of anyone who has built one yet. As they say in racing, "Speed costs
money. How fast do you want to go?" But we do know (as I've mentioned
on this thread), that receiving, timestamping, and distributing
identical messages without parsing them is always going to be faster
than processing messages, computing new graphics and damage
> 3. How do we manage colloboration with low end system, as Croquet
> places a huge need on graphic resources?
The Croquet model (and associated benefits) makes no assumption about
However, the demos in the current SDK all assume a capable graphics
coprocessor of the kind delivered on pretty much any computer you
would buy today in the US, Japan, or Europe. The idea is to take
full advantage of capabilities available now rather than developing a
next generation system engineered for obsolete computers. We would
call that "arming for the previous war."
> 4. What are the network bandwith requirements?
The code in the repositories has not been tuned. (Commercial
applications might well be.) Even as is, my experience with the
public code is that WAN performance from my home is limited by my
crummy ISP thottling my upload bandwidth to 30 KB/s. I hit that limit
sending live audio and video, until I spent a few hours tuning and
putting in some simple automatic adjustments. See http://
> Do we have any compression technology in place to reduce the
> network load?
No, there's a lot of tuning, compression and removal of junk that
needs to be done. The work to this point has been about the big math
- i.e., how things scale -- not with such trivialities as mere scalar
factors. But I feel now it's time to do that.
This post has NOT been accepted by the mailing list yet.
"Netmeeting is a Windows application for internal group meetings between Windows users. Croquet can be used for different purposes such as collaboration, resource sharing, synchronous computation among multiple users, to create powerful and highly collaborative multi-user 2D and 3D applications and simulations etc.
Using existing RDS solutions such as logmeinrescue, gosupportnow etc is beneficial as they provide easy remote access functionality.
|Free forum by Nabble - Scala forum||Edit this page|