>>Uli: And we can't display a HyperCard stack in a
>>web browser (the way HTML does it).
>>Alain: I was imagining the (eventual) process as
>>similar to embedding Quicktime or Java-Applets into
>>web pages, with the EMBED and/or OBJECT tags. Even
>>better though would be a browser REPLACEMENT (e.g
>>Web-savvy FreeCard stacks).
Uli: the trouble is, plug-ins are like images.
Alain: I am not necessarily talking about a plug-in.
Uli: They just get a rectangle in the window, and
there they are allowed to draw and they're notified of
clicks and the user typing keys. Anything that's drawn
in there is drawn using OS-specific calls, not using
XML or anything. Thus, the browser is actually only
providing the window to draw in, anything else is just
like with any other application.
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.
> Uli: Thus, XML would have absolutely no advantage in
> this regard.
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.
>>Alain: In D-HTML, with or without CSS, layers can
>>be sized and positioned with pixel-precision.
Uli: Still, we'd need pages of HTML code to describe
what would fit into 16 bytes of binary data.
Alain: Good point.
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.
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.
Alain: I was thinking of some king of HTTP-based
remote procedure calls from FreeCard components
embedded in Web pages and/or a FreeCard
browser-replacement. HTTP or some other web protocol.
Uli: I think it'd be smarter if we just had an "open
URL" command like the QuickTime Player has it.
Alain: Minimum. MetaCard is already web-savvy. Several
web protocols are scriptable from within MetaTalk.
Uli: For 2.0 or so.
Alain: I agree and always have that version 1.x of
FreeCard should aim for HyperCard as we know it now.
> Uli: To make our file format streamable, we'd need a
> special web file-format that breaks a stack into
> several files, where parts of the file are
downloaded
> separately, probably split into separate files
> (one file per card or so) ...
Alain: Sounds simple enough. Does our
block-file-format (eventually) permit this?
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".
Uli: It's all possible and within what we allowed for
so far, just not at the top of the list for now.
Alain: Couldn't (and won't) ask for more than that.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
