Another Revolution?

Fri Jan 18 15:20:48 EST 2008

Mark Wieder wrote:
> Don't bother looking too closely at what's behind the scenes. There's a lot 
> going on there, but it's deep at the server end for some obvious reasons. 
> What Tilestack has put together is pretty impressive - they've got a 
> HyperCard-to-java-bytecode compiler so that they can take HC stacks intact, 
> compile them to java apps, and host them on their server. 

It's certainly impressive, especially if they can translate HyperTalk to 
something web-native, but I don't think it's Java.  I have Java turned 
off in my browser and yet the example works well.

The source for the page is sparse:

<body>
<script type="text/javascript" defer="defer" 
src="?_twr_=ThinWire_vtrunk_r598.js"></script>
</body>

...so it was easy to just load the specified src:
<http://www.tilestack.com/?_twr_=ThinWire_vtrunk_r598.js>

...to get the JavaScript.

One thing about the web:  unless it's Flash or Java, it's publicly 
readable.  :)

I suppose that's why it's been obfuscated, but probably also for space. 
  I used to write JS obfuscators as a hobby (ah, to have that sort of 
time on my hands again), and I found I could turn human-readable code 
into mind-bendingly-concise code that was between 30-50% smaller 
(depending on how much code is in the page and what that code is doing, 
of course).

Because they left in their declarations and preserved much of their 
formatting (save white space; my obfuscators took out nearly all CRs), 
one could reconstruct a more readable version by just applying the 
declaration portion of their source to their functions below it.

I don't have that kind of time myself, but it would be a fun read I'm sure.

In my quick skim of that JS it seems they have a single XMLHttpRequest 
instance, but I haven't read it closely enough to see what they're doing 
with it to determine how much of it, if much at all, is tied to the server.

Of course this is just one example. I'm sure there's a lot to be said 
for integrating more sophisticated apps with server smarts.

> They're generating quite a bit of interest at their little booth stuck
> behind the Apple display. And they're committed to the idea that creating
> and publishing stack creations should be free, although they're still
> working on what their long-range business plan is. 

Ah yes.  "The Cathedral is Bizarre", or something like that. ;)

> I'm talking with them about extending the HC model, but obviously some
> of the rev extensions aren't going to fit into the java server world
> (file I/O at stuff like that). But if this works out it could provide
> a workaround for the single-threading cgi engine issue that 
> blocks publishing stacks to the web.

The basic idea is one I feel has much potential - I've been advocating 
it here for years:
<http://lists.runrev.com/pipermail/use-revolution/2006-June/083955.html>

It's nice to see it finally come to fruition.

But I'm not sure how one would go about "publishing stacks to the web" 
in a form that's tied to a CGI:

Stacks have both a UI and code.  The UI part is easy enough to 
translate. Alejandro Tejada Capellan was inspired by my very modest 
Rev->SVG translator and wrote a damn fine library for that: 
<http://geocities.com/capellan2000/>.  More recently, I'm porting one of 
my Rev apps to the web and finding the broad CSS support we get with 
most browsers to be a godsend for translating fields and other objects 
and appearance.

The code is the tricky part.  Do we put it all client-side in JS (or 
Java bytecode or whatever), or split the smarts between the client and 
the server?

In the app I'm porting now I'm using a little of both, with some JS to 
handle much of the UI but making extensive calls to the server for more 
data.  Determining which code goes in the page and which goes on the 
server seems like it would be a hard decision to automate.

Even when we use the server, we're not using stacks there.  We use a 
database for anything that needs to be written to, so record-locking 
just comes along for the ride.  We do use a few stack files on the 
server, but only for read-only things (we have some indexing routines we 
wrote for the desktop product that we're finding are easier to just 
leave as stack files). In such cases, single-threaded CGI isn't an issue.

Could I trouble you to explain a bit more about what you meant by "...a 
workaround for the single-threading cgi engine issue that blocks 
publishing stacks to the web"?

I'm very interested in seeing where all this goes....

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com