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 _______________________________________________ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
