>Alain: I know all of this. It supports well my idea
>that we could replace current ML-based browsers with a
>web-savvy FreeCard stack. We could probably achieve
>much more with FreeCard than is currently possible
>with ML-based browsers like Netscape and Explorer.

Alain,

  this would be perfectly possible with a streamable binary file 
format and an "Open URL" format, just like QuickTime has it.

>Alain: Unlike myself, you are linking two different
>arguments together: (1) can we eventually replace
>current ML-based browsers with a FreeCard alternative
>; (2) should the FreeCard GUI be ML-based or binary.

  I guess then I phrased it wrong. What I'm saying is: XML's advantage 
in disabled support comes from the browsers that interpret it. They 
could just as well use a binary file format to achieve the same. 
Since we'd need to add some of our own tags to use XML to describe 
FreeCard stacks, we'd also need to add a browser plugin that tells 
the browser how to interpret this different kind of XML. 
Consequently, we wouldn't be using the browser's XML display routines 
again, which essentially makes XML no longer an attractive option, as 
we'd need to add our own disabled-handling anyway. We'd be left with 
most of the disadvantages of XML in a restricted environment (the 
browser) instead of creating an unrestricted FreeCard application 
that can retrieve files through streaming via the web. Clearer now?

>Uli: If needed, we could add an exporter to DHTML ...
>
>Alain: I believe this to be a good idea. Many HC list
>members have recently signaled to me their interest in
>being able to save their HyperCard stacks as
>web-stacks e.g. a coherent set of web pages and btns
>that mirrors the structure of the exported stack.

  This could also be achieved using a FreeCard stack, it wouldn't need 
to be part of FreeCard itself.

>Uli: ... but that would miss lots of features and we'd
>have to translate FreeScript to Java or HTML links and
>"do" would become impossible, etc. It'd be pretty
>disadvantageous.
>
>Alain: Less than you believe, I venture.

  But it would make FreeCard an application to create web pages 
instead of a RAD tool. And a tool that's 100% specifically designed 
to be an HTML editor is better for creating HTML than a tool that 
allows creating much more powerful files (stacks) and to then create 
web pages from that using a lossy conversion. I think a 
web-page-designer stack that uses the basic structure of a stack to 
contain a web page would be much better suited for this task. It's 
something the UFP could already attempt on their own using HyperCard 
and XCMDs. We would later find a way to convert that to a FreeCard 
stack.

>Alain: Minimum. MetaCard is already web-savvy. Several
>web protocols are scriptable from within MetaTalk.

  We will certainly look into what other HC clones have added and 
include it as needed later down the road. And I'm sure web scripting 
will have a big lobby. But for use as a web browser-like application, 
the "Open URL" command might suffice. We could even hack in an 
HTML-viewer if needed (again, I'm toying with wxWindows, which has 
that available as a pre-written component, even though it loads 
images at a snail's speed, but I guess that'll be improved over time).

>Alain: Sounds simple enough. Does our
>block-file-format (eventually) permit this?

  The dynamic loading of the map (I.e. only the main map is loaded at 
startup, a sub-block's map isn't loaded until you're actually 
accessing it) I'm currently working on will come in handy there.

>Uli: ... as I'm not sure we can say "download byte 1
>to 7 of file x" over the web.
>
>Alain: Following up on my Remote-Procedure-Call idea,
>the HTTP protocol does support this. They call these
>"stay-alive connections".

  Well, if that works, it should be rather easy to dynamically stream 
a file over the web. I would just download the file header (which 
contains the position of the main map) and then use the info from 
that to download only the main map, and then that would be used to 
download the blocks currently needed (i.e. the main stack of the 
file, it's first background and its first card).

Cheers,
-- M. Uli Kusterer

------------------------------------------------------------
              http://www.weblayout.com/witness
        'The Witnesses of TeachText are everywhere...'

Reply via email to