>A seperate HTTP request for each item is rather silly -- it'll cost you
>two hundred bytes of headers for the request another hundred for the
>reply and a connection. All this for a little checkbox, which probably
>takes 20 bytes. Meaning that a twentieth of the actual bandwidth went
>towards the data, while the rest was overhead. Hardly an efficient way
>to do things.
>Yes, it gets far better for bigger things, like 10K scripts, but most
>of the requests will be for little things (especially if the scripts
>are seperate files) like fields and checkboxes. And buttons with the
>script "go next card" or whatnot.
Anthony,
if the headers are that big, we'll have to make the whole thing more
effective. Say, buttons with a size less than, say, 500 bytes are
kept in the same file as their card. Is this the same for FTP? That
is, what's the file transfer protocol that has the least overhead
(and which one of the ones with little overhead are the most commonly
used?)?
>It would be much better if we were to make the background download at
>once, up to say 50K. After that, large objects would be split off (such
>as that nice 24bit color image). Same with cards. 50K downloads are
>quite reasonable, even over a modem, and that really minimizes the
>overhead.
>
>The 50K chunks would need to be built by a 'export as HTTP streaming' feature.
What about this: The first card goes completely in one file,
additional cards are loaded dynamically as needed. There's a
threshold at which an object will be extracted into a separate file.
>Also, how are changes sent back? That is something that should be
>looked into. Also, we should look into security (e.g., not allowing
>someone to "accidentally" open the FC app file and write 0's to it or
>send someone's data)
Changes will not be sent back. A fully working copy of the stack
will be saved to your disk step by step, to which changes will be
applied. If you need to send changes back to the server, you'd have
to use another facility (say, a "post" command) that is then handled
by a CGI or so. We can't have users going around and changing stacks
over the web, that'd be a huge security hole. To avoid the negative
reputation that comes with such unsafe web deployment, I'd say we
leave actually implementing support for changing stacks streamed from
a server to scripters. They'd have to implement a receiveChange
message handler or whatever.
Besides that, I'd say we don't allow XCMDs (or any other kind of
plugin) over the web, and file access commands may only manipulate
files in a special folder next to the stack.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
