On Wed, Feb 18, 2009 at 2:10 PM, Eli Barzilay <eli at barzilay.org> wrote: > On Feb 18, Carl Eastlund wrote: >> >> Consider the web server as an example. We do not provide code for >> the web server that defines its configuration values and tell the >> user to "edit collects/web-server/config.ss". Instead, we provide a >> framework for the web server that is parameterized over its >> configuration. The user can then write a program or run a command >> line utility that fills in those parameters and runs the web server. >> We provide the entire framework; the user writes one or a few lines >> to kick it off, rather than editing files in our provided collection >> tree. > > To create simple a web-server application you write some code in a > file and package it up in some form that your clients can install. To > create a basic customized handin client you write some code in a file > (and it's very simple: just an info.ss file) and you need to package > it in a way your clients can install. IOW, I don't see any point > here. > > It just happens that the *actual* client code (the one in the > handin-client collection) needs to be packaged with it right now -- > but that won't be necessary if that code is included with the > student's drscheme installation. To take this analogy back to the > web server -- if it was not included with plt, then to write a web > server application you'd need to package your code and the web-server > code and ship all of that to your clients -- same deal. > > Some more details: I think that it's safe to assume that I'm using the > handin server/client pretty heavily -- so this is a version that is > supposedly going to be an extreme case of "customization". > > * What I do to setup the server is run it from a directory with a > configuration file and some additional things (like the ssl > certificate files, the hw directories etc). The server code itself > is _unmodified_ (it's actually running from the plt svn tree). > > * What I do to setup the client is: > > 1. copy the whole thing over to my own directory > > 2. overwrite server-cert.pem with my own certificate > > 3. overwrite icon.png with my own icon > > 4. edit info.ss > > 5. add a whole bunch of stuff that is specific to my course > > Now, if the handin client was included with the student > distributions, > > - I'd begin with an empty directory > > - I wouldn't need to do #1 > > - In #2 and #3 I'd "put my files" in instead of "overwriting" them. > > - For #4 I'd "write my own" info file, where this is most > conveniently done by starting from a documented example that lists > what I can have there -- a template file happens to be a very > convenient format for such work (the template could move from a > file to the manual, but it's the same idea) > > - #5 would be the same > > - Additional point: with the way things are, I'd probably need to > write stub files like a "client-gui.ss" file that has: > > #lang scheme/base > (require handin-client/client-gui) > (provide (all-from-out handin-client/client-gui)) > > But if the collection is included with plt, then it should be easy > to arrange it so the stub files are not needed. That is, the info > file will use the tool directly from the plt tree, and things will > work fine. (The main change here would be in the > "this-collection.ss" hack, which will find the collection holding > the info file instead of itself.) > > If my guess is correct, then you're assuming that I won't do that last > paragraph and that's what you're trying to complain about. This > assumption is false.
It sounds like we agree about the kind of changes to make to the handin server/client distribution process. -- Carl Eastlund
