David Lichteblau david@lichteblau.com writes:
Hand-written JavaScript code could fetch a description of the shapes to render using XMLHttpReqest, which has "XML" in its name, but can actually also fetch arbitrary text/plain documents. At least on Firefox this approach also works for documents in the local file system, so a web server is not necessary initially.
Interactive use is then just a matter of repeating these requests to wait for more events from the server or to send keyboard events back (but will obviously require a web server at that point).
I suppose another question is whether people think that this is worthwhile -- I think it's fair to say that we're fairly stretched as is; at least, I am. (I can't in all fairness make any promises at all about time I have to polish this at the moment, for instance.)
(Since you mentioned lack of a web coder, see http://www.lichteblau.com/blubba/responsetext/test.html for a trivial XMLHttpRequest example that renders a text file from the same directory.)
My epiphany says
Javascript error in on line 0: uncaught exception: [Exception... "Not enough arguments [nsIXMLHttpRequest.send]" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: http://www.lichteblau.com/blubba/responsetext/test.js :: <TOP_LEVEL> :: line 29" data: no]
I'm afraid. (But I get the idea, I think.)
So the next step could be to define a textual format that describes the shapes to render which is as compact as possible.
Made-up example for a syntax that might or might not be more compact: M42R0,0,100,100 could mean "medium operation", "the medium with ID 42", "draw a rectangle", "here are the coordinates".
Right.
I suppose another way is to compile enough of the various applicable methods that much of the responses to user interaction can be executed on the client -- it would be insane to round-trip for stuff like highlight-presentation, for instance. Again, I don't have a feel for how possible this is.
Thanks,
Christophe