[mcclim-devel] Yet another half-baked half-finished backend
Hi, I'm aware that we're accumulating broken backends faster than we are fixing them, but I'd still like to make a case for including another. Over the course of yesterday, I built enough of a backend based on the WHATWG (HTML 5) group's <canvas> widget that code which is essentially (with-output-to-canvas (s file) (gsharp:draw-buffer s buffer)) produces <http://doc.gold.ac.uk/~mas01cr/tmp/rapsoden-mostly-correct.html> (best viewed with something that's not IE; also, please don't tell me that it tells you about not supporting <canvas> even though it does). I should warn that I'm one Web Coder short of a project; I don't really have a feeling for how to take this backend much further: specifically, missing features that are moderately essential are text (<canvas> doesn't support text; apparently styled <div>s are the way forward) -- which would get the backend about up to Postscript levels of functionality -- and interactivity, which would be utterly cool but clearly won't work currently given that that html file is about 1MB big. So, any ideas? The backend itself is about 400 lines of code; should I just go ahead and check it in, or does anyone have any reservations? Cheers, Christophe
Quoting Christophe Rhodes (csr21@cantab.net):
I should warn that I'm one Web Coder short of a project; I don't really have a feeling for how to take this backend much further: specifically, missing features that are moderately essential are text (<canvas> doesn't support text; apparently styled <div>s are the way forward) -- which would get the backend about up to Postscript levels of functionality -- and interactivity, which would be utterly cool but clearly won't work currently given that that html file is about 1MB big. So, any ideas?
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). (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.) 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". If that is still not compact enough, (ab)use the full range of Unicode characters for a binary format.
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
On 7/9/07, Christophe Rhodes <csr21@cantab.net> wrote:
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.)
I think it's worthwhile. You are showing how McCLIM can be applied in a context that maybe some people didn't realize was possible, and maybe somebody new will hop on board as a result of seeing this. Would it help relieve the concerns about broken backends if the non-functional ones (such as clim-graphic-forms) were left out of "official" releases until such time as they meet some (to be determined) functionality level? Or is that policy already in place? -- Jack Unrue
I apologize if this is either old news to you all or not directly relevant, but FWIW SRI had some "web" type CLIM backend: http://www.ai.sri.com/~pkarp/clim-www/tool.html The source code is available via a URL on that page. I made some half-hearted attempts to build it under SBCL+McCLIM, but did not get too far. It definitely fell into the "yak-shaving" category for me, but it might have some relevance for you guys (if I understand correctly what you are attempting). -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 68 Moulton Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm@mak.com
participants (4)
-
Christophe Rhodes -
David Lichteblau -
Jack Unrue -
John Morrison