Posted by Howard Stearns on Jan 25, 2007; 1:02pm
URL: https://forum.world.st/Croquet-vs-Other-remote-desktop-sharing-applications-tp125505p125506.html


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