legacy apps [was:] Using HedgeHog SpreadSheet

Well, there's integration and then there's integration.

One thing the Wisconsin package in the repository does is let the user
specify a URL to create a connection to. The system brings up a shared
Remove Frame Buffer display (aka Virtual Network Computing) to a Unix
server.  If the URL ends in .doc, it brings up a Word clone
(OpenOffice). If it ends in .pdf, it brings up an Acrobet clone
(evince). No .xls support yet, but OpenOffice should handle that.
Anything else, and it brings up Firefox.

The effect is that the users of the space have a series of "virtual
table PCs" that are each dedicated to a particular application -- i.e.,
a program operating on a particular data file.  Instead of opening and
closing executables on dead files on your Windows desktop, you have
long-lived "objects" that embody the application AND the data in one.

Under the hood, there's a little protocol whereby the Unix server is
running a little python HTTP server to launch these applications in a
sandbox. That is, you don't see the full Unix desktop -- instead, each
virtual tablet PC panel is trapped to just that one application.

There are a couple of issues here. Some temporary, some deep:

* It's relatively slow. This is improving rapidly as we tune it, but I
don't think it's ever going to be fast enough to run First-Person
Shooter games in a browser on a remote system within Croquet. It should
(soon) be fine for .doc or .pdf or normal Web browsing.

* Neither the application nor the data are "in" Croquet. Suppose you
edit a file and want to save it. As it stands now, it would save on the
server. Managing files and versions and copies is a mess that Croquet is
successfully designed (as I view it) to avoid. But this non-Croquet
stuff brings those issues back. Also, for the server to see the file in
the first place, it has to be world-accessible via http so that the
server can fetch it via the specified URL. We can address both these
issues after a fashion by having a means to get files from/to your disk
to the server, but that's not a Croquet issue.

* As with any shared VNC application, all users have the same security.
I hope and believe that long-term, we can arrange for different security
to be on different UI objects that at least appear to be within the same
space. But this is a bit past my current time horizon. And even then, it
will only allow for different access for different users of different
Croquet objects (e.g., the display panels), not for individual
operations within the foreign application. (I.e., we can't fix Windows(TM).)

* This approach essentially makes a window that punches a whole through
the fabric of Croquet to legacy applications. Some consequences (in
addition to file management and access) are that the model of time and
objects is different. Croquet is designed for everybody to see the same
thing at the same Croquet-time. What's happening on the VNC server is
happening in the server's real-time. And the objects at the far end of
the VNC "window" or "tunnel" can't interact with objects in Croquet. For
example, you can't drag an object within a foreign Web browser off the
display panel and onto some other Croquet object. These issues probably
don't matter at all for legacy applications, which aren't designed to
support coordination between applications anyway. But as Croquet
environments get richer and get designed to take advantage of such
concepts, a VNC-based solution is going to start looking pretty hokey.

All these issues are not peculiar to RFB/VNC, of course. You could do
use the RFB stuff as a model to punch an analogous hole to display LOCAL
Java, .NET, or whatever you want. Andreas has written a powerful
EmbeddedApplication framework that is used underneath the RFB stuff. One
additional issue you would face (that RFB covers) is what should other
folks in the space see? Do they need to have the same applications and
data files on their computer?

kiran wrote:
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

As AJAX and Web 2.0 / Office 2.0 become more popular, perhaps a strong JavaScript emulator and web browser embedded/created in Smalltalk could provide most of what most people need in integration to external applications and yet retain security and object interactivity.

What do you think, Howard?

Cheers,
Darius

I don't know enough about the latest [AJAX | DHTML | ActiveX | Java |
Web2.0 | single-user-fat-client-du-jure] models to assess how much risk
there is for an impedence mismatch, or how significant the consequences
would be (if any).

For example, Croquet works on the idea that the same inputs on the same
initial conditions gives the same results. Because of this, it doesn't
have to check that all parties are still in sync. Croquet accomplishes
this with a unique model of time and a VM that gives the same results
across different platforms.  It's no problem to start an embedded
application on each participant's machine at the same Croquet-time, and
have the same inputs given at the same Croquet-time. But now suppose
that the embedded app moves a bouncing window around based on the local
machine clock-time expired between successive mouse positions. Or
suppose that one machine decides a result is an "even" float and the
other decides "odd."

On some apps this will matter. On others it won't.

I imagine that there's also some work to be done on portable pickling
(serializing). If someone joins late, they need to get the right
starting state. But that's just work, and probably not much work
compared with actually building the JavaScript emulator, browser, DOM,
etc. (There's a trivial example of this in our embedded text app, which
updates the replicated string at each input.)

Are you asking because you have a particular application in mind, or on
spec because it's "a good idea?"

Darius Clarke wrote:
> As AJAX and Web 2.0 / Office 2.0 become more popular, perhaps a strong
> JavaScript emulator and web browser embedded/created in Smalltalk could
> provide most of what most people need in integration to external
> applications and yet retain security and object interactivity.
>
> What do you think, Howard?
>
> Cheers,
> Darius

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

Just asking based on the principle of making two environments similar for a visitor/programmer so that they can still work with what is familiar (where all their data, services, and utility exist) and still gain the benefits of what is better.

An minimal example of using Scamper as an EmbeddedApp within Croquet  
is UnderwaterWorld>>makeWebPage:extent:.
The idea here is that a Morphic Scamper application is created as an  
EmbeddedApp, and inputs are replicated to each participant's local  
copy, which is operating in its own local Morphic World outside of  
Croquet.  Note, though, that this example does not replicate state  
within Croquet, so folks joining late are out of sync on the Morphic  
side.

I don't know what you mean with respect to Firefox and this  
situation. The stuff I was talking about with Firefox does not use  
Scamper or a local Firefox. It replicates a shared VNC session to a  
single common VNC server running Firefox. This way, the shared state  
is maintained by the VNC server. XrfbClient>>url:objectID is used to  
provide a "session key" that folks joining synchronously or late can  
use to talk to a special little (non-Croquet) HTTP server on a (non-
Croquet) VNC server box to map that key to a VNC display number. The  
morphic RFBClient  superclass then uses this to connect to the shared  
session with the appropriate state.  This is a different approach  
from what I interpret you're saying below regarding Scamper and  
HTTPSocket.

All of this emphasis on state should tell you something: Croquet has  
a very elegant model that replicates computation rather than state.  
Go outside of Croquet, and you're back to trying to replicate state  
for that foreign application. Not cool.

On Jan 5, 2007, at 5:11 AM, kiran wrote:

kiran wrote:
> Firefox issue i understood your answer totally.
> Basically, we need to go through VNC/RFB for all non-croquet applications/platforms.

Well, no. This isn't the only way. It's just that this is one of the
ways in which I know that someone has worked though the issues and for
which there is a working example.

>
> Let me ask this novice question. Sorry for this if sounds too simple.
>
> How do i access say a google page programmatically..that my major question?
>
> I tried HTTPSocket httpget:'www.google.com'.
> It yields only HTML tokens. Pls tell me how to resolve this..
> In the same way i am trying to invoke a ASP page. Is this wrong?

I'm not sure if this is what you're asking for, but I just now added a
third line
    ('http://www.google.com' 20 1 -22 -30)
to the data set in UnderwaterWorld>>initialize that is used to make
sends to #makeWebPage:extent:.

It works fine, in the sense of getting the Web page and displaying it.
But note that this is only meant as a very cursory example of an
EmbeddedApp:
   -It uses Morphic, and hence has the state synchronization issues I've
been talking about.
   -It uses Scamper, which isn't a very good Web browser. In fact, this
particular usage is as an Editor of the stuff displayed, not as a an
interactive (i.e., hypterext linked) Web browser.

>
> Thanks so much for taking trouble in answering this.
>
> Thanks
> Kiran
>
>

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

Delete cache/UnderwaterWorld.c3d and try again.
-Howard

On Jan 8, 2007, at 3:50 AM, kiran wrote: