Another Revolution?

[Richard Gaskin]

Mark Wieder wrote:
> Sheesh.
> It's java.
> 
> I spent enough time with the developers over the last few days to get that 
> right.
> It's java running on their backend servers, not in your web client.
> That's why you won't be able to see it from the client side.

I must be using the wrong nomenclature, as this distinction is 
frequently lost in discussions of porting stacks to the web:

Whether they use Java, Ruby, Perl, C, or an army of methamphetamine 
addicts outsourced from Bakersfield typing really fast, what's being 
done on the server is distinct from what goes on in the browser.

I mean, of course they're related in that the server generates the page 
and delivers it over the wire to the browser.  But my point here is that 
what's used on the server could be nearly any language in the world, but 
what happens in the browser can only be HTML, and must rely on 
JavaScript, Java, or a plugin for any interactivity.

This distinction is useful here because most of us xTalkers are 
accustomed to a world where UI and code are bound together to one degree 
or another, in contrast to the web where the UI (what happens the 
browser) is separated from whatever may be delivering data to it from a 
server.

So when we think of a "stack" and then we see a page like the example at 
TileStack.com, we ponder how it's done.  Whether it was served up as a 
simple ASCII file containing the JavaScript, or the JavaScript was 
served from a database, or the JavaScript was generated in real time by 
an application written in any language that can write text, or the 
JavaScript was typed by the aforementioned meth addicts directly to the 
port, what we're interacting with is JavaScript.

Given the strengths and weaknesses of each of the common three (JS, 
Java, or Flash), which of those three is used will define much of our 
expectations for the technology.

Personally, now that CSS is universally supported, I prefer JavaScript, 
since it's more broadly deployable than Flash or Java.  Sure, JS has its 
warts, but so does everything else.  So I'm really glad the folks at 
TileStack have chosen it to deliver their UIs.


> There's been a lot of discussion on this list over the years along the lines 
> of <whine>I wrote this great game. why can't I just publish my stack on the 
> web</whine>. And after quite a bit of research it turns out that since the 
> rev engine is single-threaded and stacks aren't really designed to be 
> multi-user and reentrant within a thread, you run into several issues trying 
> to use rev as a cgi-engine. For instance, http has no concept of a session: 
> each request is a new transaction. This doesn't bode well for a cgi engine 
> trying to keep track of user variables. If you run fast-cgi then you keep 
> your persistence but each new session has its own memory space.

If I read this correctly, it sounds like these are issues that only 
affect collaboration, but not issues at all for single-user applications.

For example, if I run a copy of Malte's Drops game on my machine here, 
and you run yours there, it doesn't matter that our computers don't 
share any data.  We each enjoy the game anyway.

So if Malte rewrote Drops in JavaScript or Flash, it's still the same 
game and still works just as well as it did before, your copy in your 
browser and mine in my browser.

But if instead of Drops we were playing Chess, then we'd need a 
connection between us.  As Rev stacks we could use ports, but as 
JavaScript in a browser we'd have to go through a server.

In this Chess game, do we really need, or even want, to be using stack 
files on the server?  What for? Why not do what the rest of the world 
does and just use a database or some other inherently multi-user mechanism?


> ...stacks simply won't be publishable on the web as written using
> the rev cgi engine. *Unless they're specifically written to be web
> stacks, avoiding the problem areas*. And yes, it's certainly doable,
> and fairly easily. But the point is that you have to think of
> designing a stack for the desktop or designing it for web use. The 
> two are rarely going to coincide.

Isn't that what TileStack is all about, making web apps exclusively for 
the browser?

Or do they actually translate Transcript?  That would be cool, but seems 
like a lot of work for a relatively small audience.

Or do they translate HyperCard stacks?  Again, way cool, but after more 
than a decade since Apple dropped HC it would also seem a small audience.

I guess that's the missing link in all the excitement here, getting an 
understanding of the authoring process.

Did you get a look at how to make a TileStack app?
Is there also a way to deploy desktop standalones?
What distinguishes TileStack from other visual web development tools?

Or maybe an ever better question:  Could there be an opportunity here 
for the folks at TileStack to collaborate with RunRev for porting 
applications between the web and the desktop?

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