On 5/1/06, Michael Tobis <[EMAIL PROTECTED]> 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é _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
