Croquet vs Other remote desktop sharing applications

Hi,
  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...
Regards
Kiran

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.

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.

David

 kiran wrote:
> Hi,
>   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...
> Regards
> Kiran
>
>  

On Jan 22, 2007, at 9:51 AM, David A Smith wrote:

Continuing this high-level explanation just one level of abstraction  
down, there are several beneficial outcomes from this replicated  
computation concept:

* 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.

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.   :-)

kiran wrote:

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.

<rant>
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.
</rant>

> 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  
accomplish.

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  
rectangles, etc.

> 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  
graphics.

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://
www.wetmachine.com/item/685

> 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.

>
> Thanks
> Kiran
>
>

"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.
"