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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
