This is pretty cool, and definitely something that is needed. In terms of images etc, I see these as resources that are referenced by the expressions going over the wire, rather than embedded in the expressions directly. You can just send the url to the image (or data later turned into a url), and then the resource is loaded in the browser via http.
Continuing my html5 repl rationale at http://groups.google.com/group/clojure-tools/browse_thread/thread/f0ef25f5489b4554?hl=en On Fri, Feb 24, 2012 at 11:39 PM, Chas Emerick <c...@cemerick.com> wrote: > That's a nice summary, and is part of what I'm hoping to enable with > nREPL.[1] I started with it trying to provide a tool-agnostic REPL backend, > but I quickly wanted to get past the rigid text orientation of that medium. > Yes, Clojure forms are always read as text, and that's the dominant medium of > interaction used by programmers everywhere, but it doesn't (and maybe > shouldn't) be that way. Certainly, the leverage provided by well-executed, > relevant, perhaps-interactive visualizations is becoming widely appreciated; > I don't see why we should allow our programming practice to be segregated in > a text ghetto when different mediums are better — or necessary. > > Anyway, nREPL has developed to the point where middlewares can be written to > easily offer richer representations of data within the REPL. An example of > my earliest (primitive!) experiments around this are available here[2]. > Images and other data flowing through a REPL isn't a _huge_ deal, except that: > > * nREPL is tool-agnostic; reply (and therefore Leiningen v2) or vimclojure or > jark or textmate or sublime text can elect to receive those other > representations, and present them to the user however is appropriate > > * nREPL is transport-agnostic; the default socket transport (bencode[3] with > some particular semantics) is very lightweight, and can receive or transmit > binary data efficiently (a distinct advantage compared to shipping textual > encodings of such data in e.g. s-expressions). > > A proof of concept of a tty transport is included in nREPL (so you could > connect to an nREPL backend using something as meager as telnet), and I have > a sketch of an nREPL ring handler that I'll get out on github soon. This > should allow you to easily drop an nREPL endpoint into any ring app, connect > to it with any HTTP or nREPL client, and do anything you'd like to do in a > REPL without tunneling, mucking around with ssh tunnels, and taking advantage > of all existing webapp security regime you have in place. And, if you have > the right middlewares in place and a suitably-capable client, rich > representations of REPL data and rich interactions with the same should be > within arm's reach. > > I have less of a vision for the HTML5 side of things. I'm certain a killer > in-browser nREPL client could be put together to take advantage of all of the > above, whether it's connecting to an HTTP nREPL endpoint or a (web)socket > transport using nREPL's wire protocol, but I'm personally more interested on > "thick clients" (perhaps embedding webviews as necessary!) for various > reasons. > > FYI, for anyone working on tooling to help support things like this, I'd > invite you to join the clojure-tools group I created recently: > > http://groups.google.com/group/clojure-tools/browse_thread/thread/48ff47ab5d7ca2c?hl=en > > Cheers, > > - Chas > > [1] http://github.com/clojure/tools.nrepl > [2] > http://cemerick.com/2011/10/26/enabling-richer-interactions-in-the-clojure-repl/ > [3] It turns out that bencode and the way nREPL uses it seems similar to but > much simpler than Google's SPDY protocol. > > On Feb 24, 2012, at 5:33 PM, kovas boguta wrote: > >> That's a great talk, and a great basic principle: that creators need >> an immediate connection to their creation. >> >> I realized this has also been my side project for the last few months, >> though mostly in "hammock phase". >> >> I think the foundational technology we need, as a community, is an >> "html5 repl". You type code into the browser, and can create output >> that takes advantage of the host's capabilities - graphics, video, UI >> etc. >> >> The problem is a bit more multifaceted then just html though, as it >> also involves UI state, persisting the sessions, how to share/reuse >> the creations, and the general problem of UI description in the >> context of clojurescript. >> >> But where this gets you is this: a clojure interaction environment >> based on web standards, rather than narrow dialects like elisp and >> swing. So the lines between programming clojure, extending the clojure >> programming environment, and deploying webapps goes away. It's >> possible to see a line between this category of tool, and the demos in >> the presentation. >> >> If the game is tightly coupling data, code, and complex visual >> representation, we have the building blocks to bust that game wide >> open. It makes no sense to build on a platform other than the web, and >> IMHO the big step there is to program clojure from the web, to produce >> fully-active web content. >> >> Another aspect of immediate connection, and one not mentioned in the >> talk, is the social aspect. You make things, and show them to people, >> get feedback, see things others have made. Now imagine if the clojure >> community was creating in a system that is inherently web based. Many >> interesting things could be built on that. >> >> >> On Fri, Feb 24, 2012 at 4:27 PM, Raju Bitter <rajubit...@googlemail.com> >> wrote: >>> Thanks for posting the link. I've been following Bret Victor's blog >>> and the stuff he has been doing for some time. >>> >>> Bret has built some very impressive UIs using OpenLaszlo, and he is a >>> fan of the technology and the expressiveness of the LZX language for >>> building UIs. OpenLaszlo was created by bunch of smart folks and >>> Lispers, including Oliver Steele (worked for Apple on Dylan), Max >>> Carlson, Tucker Withington (worked for Symbolics and Harlequin, >>> implemented the GC for Dylan when Apple hired Harlequin to work on the >>> language), and Henry Minsky (Marvin Minsky's son). >>> http://osteele.com/ >>> http://pt.withy.org/ >>> >>> Here's an old gestural zoom/pan demo Bret built with OpenLaszlo: >>> http://worrydream.com/GesturalZoomAndPan/ >>> >>> OpenLaszlo's LZX language uses a declarative approach to building UIs >>> and highly interactive applications (check this video of the Laszlo >>> Dashboard, which was created in 2002/2003 http://vimeo.com/14206607). >>> LZX is a mixture of XML tags + JavaScript, which initially was >>> compiled into SWF bytecode. In 2007 Laszlo added cross-compilation to >>> JavaScript (DHTML runtime) to the platform, and in 2009 >>> cross-compilation to ActionScript 3 (which is then compiled into SWF >>> using the Flex SDK). >>> >>> Here's a video of the LzPix application, the first OpenLaszlo app to >>> cross-compile to JavaScript >>> http://vimeo.com/32853986 >>> >>> My technology dream-team for client development would be ClojureScript >>> combined with OpenLaszlo (has a powerful view kernel with interesting >>> stuff like constraints, datapath mapping using xpath, simple yet >>> powerful animation APIs). Instead of using XML + JavaScript, I'd >>> prefer to use a more Clojure/Lisp like syntax to build UIs with >>> OpenLaszlo in combination with ClojureScript. There's a slight chance >>> that we can get the OpenLaszlo Lisp folks interested in integrating >>> OpenLaszlo with ClojureScript (they are all working at Nest Labs now), >>> and I'm sure that Bret Victor would love the combination as a tool for >>> building some awesome prototypes. >>> >>> - Raju >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
