I was intrigued with the idea of a "Try Python" web site that I read about recently. Inspired by an idea originally mentioned by Steve Howell to create Webster van Robot, a web version of Guido van Robot (which itself was the inspiration for rur-ple) I have been wondering about the possibility of creating a version of rur-ple (only Reeborg's world part) that would run in a standard browser, just like one can use "Try Python".
There are two versions of "Try Python": Mike Meyer's, and Devan Lai's. While Devan (a very promising 14 year old programmer, imho) in a post on comp.lang.python wrote that Meyer's is the "cooler" implementation of the two, I personnally think that Devan's is the cooler of the two, and the one with the best potential for showcasing rur-ple as his version can already accept function definitions (and probably more; I just had a very quick look at both).
Now, I know very little about web stuff. One thing I know is that, for "games" type object, it is
Now, I think that, if having a version of rur-ple on the web were to be done, it could generate a lot more attention on Python, and on the web framework that would have been used to develop it if using one of those fancy web frameworks is required.
Nonetheless, if one was to really showcase Python using rur-ple on the web, I think the following requirements would have to be satisfied:
- It should not require the user to install a plugin in his/her browser, just like it is done with the "Try Python" sites;
- it should not require a special browser, like Grail, either;
- it should not require some fancy javascript, but only html and css - remember, it is Python we want to showcase; along the same lines, it should not be implemented via a Python applet. Using Jython would be almost like cheating, imho.
Can this be done using one of these famous web frameworks that are generating so many discussions, including the one spurred by Python's bdfl? I personnally have no idea... One thing I know for sure: if it is, I will have to do some major refactoring of my code as the gui stuff is too much intertwined with the logic part; I had no concept of the model-view-controller approach when I started creating rur-ple, and I had no clear reason to try to conform to it (if it ain't broke...) later on. But, given a strong enough incentive, I could always do it!
2 comments:
If you want to do this right, you'll have to use quite a bit of Javascript. But that's okay -- it doesn't mean you have to make the app user deal with Javascript.
I doubt it will look much like normal graphical programming, but maybe that's fine. One thing that can be interesting is that instead of just the standard REPL loop that these apps provide, it wouldn't be a long step to allow object to have html representations, so instead of just using repr() to show what the result of the last line was, you could show arbitrary HTML. That HTML could be interactive on the client side of course. That HTML could also call back to the original object, and so represent a connection with the server state, which is where it gets more interesting.
In that model the "widgets" are largely implemented in Javascript, and presumably you would be providing them as part of a standard library provided. If you look at the Try Ruby tutorial, it involves some of this, though I don't know if it goes as far as actual RPC and callbacks. Anyway, then you'd be building them up in Python, and the HTML and Javascript would be part of seemingly opaque objects.
The hard part is server push, though -- where anything starts from something on the server (and thus where anything starts from Python at all). Instead it all has to happen in response to a client-side action, like the user hitting Enter or clicking on something. Using Twisted and LivePage you can get server-side events, or using a polling loop where you constantly ask "anything yet?" -- and maybe Aquarium would also allow it (Aquarium uses some similar techniques to Twisted, but by using the Stackless Python interpreter it makes them easier to work with.)
Anyway, I think it could be very interesting. Also it could let users create fun little web applications, which is easy to work with (no software install) and in particular is easy to share (which is a big motivator).
Ian:
Actually, instead of having HTML [instead of just using repr(), as you mentioned], I was thinking that what could be sent back from the server could be a series of "states" representing the image to be displayed. For example [(1,1), (1,2), (2,2)] could be taken as asking to display the robot at position (1,1), wait for a preset time amount, display it again at (1,2), wait ..., etc. Of course this is overly simplified. Javascript would be used to interpret this series of states.
So, the user would write the code in a window (html frame?) click a button; the code is sent back to the server, where it is interpreted by Python, which sends back a series of "states" which are then turned into an animation with some javascript code on the client side, animating a picture in a separate frame?...
I think what I will do (after I complete version 1.0 of rur-ple) is decouple the logic from the gui handling and try to rebuild it (still as a Python app) along the same line as I describe above - except that everything would be done in Python of course! Then, I could try a local version with some javascript handling the visual display from a state. After that, I'll shout "HELP" and see if someone is willing to implement the server-client "stuff".
That is to say, unless someone demonstrates to me that what I describe is nonsensical - or come up with a simpler way.
Of course, I won't refuse help from anyone in the meantime;-)
Post a Comment