Revision 6 as of 2003-02-22 07:30:18

Clear message

About Me

Hello! I'm Leonard. This is my first conference talk. I'll keep this page updated with information as I scramble to get the talk and the corresponding software written in time. :)

If you're interested in me personally, you can visit [http://www.crummy.com/ my homepage].

Talk Synopsis

Oftentimes, a very small or very new web application will keep all of its configuration settings inside the code itself (hopefully as variable settings in some obvious place). To change the configuration, a user must become a developer of the application. For example:

    #Whether or not to enable image uploads
    ENABLE_IMAGE_UPLOADS = 1

    #The maximum size of an uploaded image, in kilobytes
    MAXIMUM_IMAGE_SIZE = 100

A larger, more flexible, or more mature application may keep its configuration settings in a text file loaded by the application at runtime. When configuring such an application a user is changing data, rather than code, and acting as an administrator rather than a developer. Python's ConfigParser module provides built-in support for this level of flexibility, for example:

    [Images]
    enable-image-upload=1 #Whether or not to enable image uploads
    maximum-image-size=100 #Maximum size of an uploaded image, in kb

The natural next step towards better usability is to provide an interface to the configuration file from within the application itself, using the same framework and UI standards found in the rest of the application. This allows a user to configure the application while remaining just that--a user:

    Enable image uploads? [X]

    Maximum image size? 100___ kb

The easiest and best way to take this next step is to use a configuration framework.

The purpose of my talk is to get more of the world's configuration data out of configuration files and into configuration frameworks with Web interfaces. Configuration frameworks are easier to use, can enforce configuration semantics, and don't require shell access to the hosting machine. The framework I'll describe is also useful for doing a user preferences engine.

The framework I'm using in my talk is based on the one I wrote for [http://newsbruiser.tigris.org/ NewsBruiser]. [http://newsbruiser.tigris.org/source/browse/newsbruiser/nb/lib/IWantOptions.py Here it is in CVS.]

My talk is currently [http://www.python.org/pycon/pycon-schedule.html scheduled] for 11:30-12:00 on Thursday, March 27, in the Elliot room, wherever that is. I assume there will be signs.

To do

* Write the slides!

* Write 3 simple example apps to do the same thing (or one app which can get its variable in any of 3 ways):

* Write more complex app that sets global options (context == None)

* Write example app that sets per-user options (context == username)

Questions For You

First, does what I'm talking about here even make sense?

Second, what kind of apps should I write? I'd like them to be extremely simple, with only one screen apart from the configuration screen (if there is one). I'd like the "complex app" mentioned above to be configurable by at least a boolean, a text box, a drop-down selection, and something with extra semantics (like a fractional value or a year).

An example of the simple app would be something that prints out a string some configurable number of times. An example of the more complex app might be a silly text generator that reads a web page and does something to it (what it does being controlled by the configuration interface).

Work Log

02/21: Got all the NewsBruiser-specific code out of Options.py. To celebrate, moved it out of NewsBruiser proper and into the lib/ directory. It's now a reusable library called [http://newsbruiser.tigris.org/source/browse/newsbruiser/nb/lib/IWantOptions.py I Want Options].

To get all the code moved out I had to define a plugin class (it's currently called 'wrapper', but that doesn't make much sense) which contains application-specific code and is passed into the OptionGroup and Option constructors. It basically simulates a superclass of all the Option classes, so that you can change the generic Option behavior without having to change all the Option classes to subclass a different class. There might be a design pattern that describes this which would make renaming it easy. Or it might just be an OO hack, in which case I'll probably call it "Implementation" or "ImplementationDetails".

02/19: Yesterday I worked on cleaning up Options.py: moving out NewsBruiserisms, adding comments and PyDoc. I tell myself that this is useful work for the talk and not just a heavily disguised method of procrastination. Today: more of the same. Also set up this wiki page.


CategoryPyConSpeakerPage

Unable to edit the page? See the FrontPage for instructions.