Displaying Stacks in Browsers

[Alain Farmer]

Hello Ray and Richard,

>> Ray Horsley asked :
>> It may sound a bit dreamy, but does anybody
>> know of a way to display a stack in a browser
>> for normal interactive use with the cgi ... ?

> CGI is an interface for processing data
> from a client to an HTTP server.

IOW, CGI is a server-side protocole for passing-on the
processing of a web-client's request. More often than
not, the request is to store the data being submitted
to the server via a client web-form.

> it sounds like the question here is
> about the client-side presentation.

I concur.  ;-)

> Web pages are commonly done in HTML...

Increasingly xHTML, e.g. close-to "plain ole HTML" but
more rigorously coded, and wrapped in XML. Plain HTML,
for example, allows you to have un-terminated tags; in
xHTML, *all* tags have to have their corresponding end
tags (ex: <td>.....</td>). It's a bit more effort, but
the result is something far more compliant. :-)

> sometimes augmented with interactivity
> via JavaScript

Indeed. :) Albeit almost anything requires a little
bit of it. Example: plain ole "roll-overs", eg image
changes when you pass-over it with the mouse. Forms
often require a bit of JavaScript too. And so on...

> (what the young 'uns call "AJAX").

This may be evident but : AJAX is JavaScript *based*,
but JavaScript and AJAX are not the same thing. AJAX
uses JavaScript to post short, special requests to a
server, which the server reacts to by sending a short
snippet of code (instead of the traditional web page)
in order to allow the client-side browser to readjust
the layout of the page without switching or reloading
the page. iow things change inside your *dynamic* web
page without the overhead of reloading the [new] page.
You can therefore have collapsible areas.. and so on,
just like *real* softwares feature. :-))

> Browser plugins can provide support for other
> elements beyond text and graphics, such as the
> Flash plugin.

Flash is interesting, but it doesn't understand stacks
nor can it even read them. To put it bluntly: Flash is
not an xCard. It's a MacroMediaInc product, and so was
Director which, in turn, had a scripting language that
was inspired by HyperTalk, in its early-days, but that
is about as close as Flash gets to being an xCard. :(

> The challenge with plugins is that, like an
> application, if they're not already bundled
> with the browser they need to be identified, 
> located, downloaded, and installed before 
> the media can be viewed.

Even when they are already bundled with the browser,
plugins eventually need to be updated ; more often
sooner, than later. And frequently (in some cases).
And one does not always have the liberty to install
and run new apps|plugins; at work and at school for
instance. IOW, I concur that we must avoid plug-ins
whenever possible.  :-|

> There isn't currently a browser plugin
> for viewing Rev stacks...

Btw, there is such a plugin for SuperCard.. I forget
the name now.. but I know for sure that there is|was
one. Check it out if SuperCard interest you, Ray. :)

> ... through there are three
> great options which satisfy most real-world
> requests for this sort of thing:

Perhaps MORE than THREE!  ;-) 

> 1. JavaScript/DHTML/AJAX: Check out Google Maps.
> A lot can be done with plain text and graphics, 
> without the need for supporting a proprietary
> binary file like Rev.

I'm getting a little ahead of myself here, but I'd
like to point out to you both|all that the interface
of XulCard(*) is likely to be crafted with JavaScript,
DHTML and (AJAX or XUL). XUL has been around longer,
but I must admit that AJAX seems to have most of the
momentum these days. I'm going to let this 'struggle'
play-itself-out while I focus on the server-side half
of XulCard.

(*) Here is the background now : XulCard will be a
100% Web-2.0-savvy xCard. It will be quite different
from any existing xCard, including HyperCard and Rev.
Most of its properties are CSS-properties. XulCard's
dates, times, numbers, and so on.. will be based on
existing W3C|web standards. The server-side XulCard
engine is also web-standards-compliant. It's coded in
RDF (XML, with a semantic twist). Exporting stacks to
this RDF is what I'm *completing* right now. :) Next
step is the RDF-parser which I may implement with Ken
Ray's "STS XML-lib" ... then it will be XUL or AJAX
for the web based GUI. Not *easy*, to be sure, but it
is well on its way! :-))

> 2. Custom browser : Check out Google Earth. It
> provides MUCH better interface than Google Maps, 
> taking full advantage of all the things that a
> dedicated application can do. Building net-savvy
> apps in Rev is a snap.

The first clients of XulCard will be XML-RPC-savvy
client-apps (any) and why not MC/Rev in particular!
Remotely controlling one xCard with another isn't my
goal, but this XUL and/or AJAX stuff might take some
time (to ascertain the winner, to iron-out the kinks,
and so on). So, meanwhile, one will be able to use XC
without waiting for its native-GUI to be completed. :)

> 3. Consider Flash: It's already pre-installed
> on most systems, and can be used to make some
> great UIs.

It's a good choice when plugins are an option. Flash
can make some pretty *flashy* stuff. :) It is not an
xCard, and it has a steep learning curve, and it is
commercial software that you gotta purchase in order
to author your Flash content, but... it's now and it
works, and its plugin is bundled with many browsers,
so.. go for it!  :)

>   Richard Gaskin
>   Managing Editor, revJournal

Respectfully,

Alain F.
Self-employed

P.S.: I will keep y'all up-to-date, with regard to
progress being made on XulCard, if y'all want me to.
If, OTOH, this (XulCard) is considered off-topic for
this list, then I will refrain from disturbing y'all
any further.

P.P.S.: XulCard does NOT, and will NOT, compete with
Rev because Rev is a desktop-app, while XulCard is a
web-app. Moreover, they don't have the same objects,
nor the same properties, nor the same interface, nor
the same customers, etc. :-)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com