[Edu-sig] Learning Python via a browser: looking for a name

[Andre Roberge]

On 5/1/06, Michael Tobis <mtobis at gmail.com> wrote:
> We are thinking very much along the same lines in terms of the
> experience we intend to provide to the student.
> ... [snip]
> I think we should coordinate so that our efforts can cooperate. I
> think these goals are not competing; the didactic doctests and the
> authentication doctests serve different purposes.

Agreed!

What we really need, I think, is to think of what kind of pedagogical
material needs to be developped, and how we would want to have
the user interract with  it.   My approach, which I see as being just
a prototype, should allow us to experiment with different models.
>
> A well-designed interactive tutorial environment is something we all
> want, and I encourage your efforts in this direction. The crucial
> issue, I think, in the success of such a project is ease of
> deployment. The student must have either an egg to hatch or a web page
> to visit.

If the student has Python on his computer, my little app could be
delivered as an egg or downloaded from a web page.

> However, I am surprised to find myself inclined to the specialized
> client rather than the web solution. (The "rich client" or "iTunes"
> model)

My current approach is that of a desktop app (i.e. the server
and the client are running on the same computer).  When I start
the application, it starts the server and launches a browser window
(or, in my case, if Firefox is running, opens up a new page in a
separate tab).
>
> The server must either be 1) very easy to install (the skills at a
> typical school are shockingly low) or 2) low maintenance and highly
> scalable (so that skilled volunteer efforts would be sufficient.
> Either of these approaches becomes more difficult as the graphics load
> is moved to the server.

My approach requires that the following be installed on the computer:
1. A browser
2. Python :-)
3. Elementtree  (included in Python 2.5?)
4. CherryPy
5. My yet-unnamed app.  It could bundle CherryPy so that it would be
a single app to "install", if Python is already present.

> A localhost solution is not going to be deployable at all, I'm afraid.
> We will never have the tech support resources to get webservers
> installed on every student's computer.

I see that Kirby addressed this point in his reply.
>
> I guess this means you do need to address the sandbox question, which
> in turn puts quite acomputational load on the server and a time and
> skills demand on the sysadmin. Then if you do server side greaphics
> rendering, you will have a hard time getting satsifactory performance,
> unless there is *serious* infrastructure funding. It also assumes that
> the student has reliable broadband.

The sandbox question should be adressed if it is to be run from an
external server.  As for the performance, for non-graphical stuff, it
should be fairly fast as is.  Using things like AJAX (which I know very
little about - just to throw an acronym at you ;-), when can exchange
a minimum amount of information, reducing the need for broadband.

For graphical stuff ... I did a small experiment where I launched a
pygame window from the code entered by the user [me :-)] in the
browser window.  It was just a proof of concept thing that I need
to work on to make it better.
>
> So for scalability, deployment, and support as well as security, I
> think computations should be done on the client, and the end user
> should not be required to run a localhost server.

Doing (Python) computation on the client is what I already do; the
localhost server is just a small addition (if doing intensive graphics stuff).

André