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