This page gives an arbitrary, partial selection of the projects I care about: that seem like interesting research ideas, or good features for programs I distribute, or programs I'd use if they existed. It's probably biased towards smaller things I'd otherwise forget. Please email me at kohler@icir.org to discuss.

• Make Click's driver loop more adaptive. The driver loop can be summarized like this: ``Run 128 tasks. Every run (= 128 tasks), check to see if the driver should be stopped. Every 32 runs (= 4096 tasks), check to see if any timers have expired. Every 256 runs (= 32768 tasks), run the Linux scheduler.'' This works pretty well as long as tasks are cheap; unfortunately, sometimes they're not. A single task can take several seconds to complete (for example, some dump-reading elements when given a low SAMPLE rate). One answer is to make tasks uniformly cheap, but that's too restrictive. Better would be to make Click's driver loop adaptive: if it takes too long, it reduces the number of tasks per run, or runs per timer-check. Some profiling would be useful, too: maybe, at user level, it'd be equally cheap to check timers every single run.
• Improve FreeBSD kernel Click. BSD Click's file system support is rudimentary, and it the module as a whole isn't well tested.
• Add write-read handlers to Click. This would add an RPC-like semantic to Click's current read-only/write-only handlers. You could open a handler with O_RDWR permission. (Maybe if O_TRUNC isn't supplied, the handler is read first.) After writing, the flush() system call would call the write-read handler with the accumulated data; that handler would return a string which the user could read from the file. Hard to seek() in this model, so we'd probably disallow seek() on all handlers. From discussions with Luigi Rizzo.
• Click for network simulation.
• Click regression test suite.
• Click element repository.
• Click configuration checking tools. ``Packets following path XYZ will be missing the IP header annotation, which Z requires,'' and similar checks. Does any generic checker/optimizer exist for this kind of compiler-like graph property?
• The übertool. A language/system for writing more general Click tools; basically a generic optimizer. Specifies dataflow properties of elements and what to do when a particular element exhibits a particular property.
• Operating system ideacule: progress bars on the command line.
• Compound element keyword arguments.
• Package up and distribute the ipaggcreate/ipcounter program.
• T1utils should handle fonts in Type 2 format but not CFF format (that's a separate project).
• A program that translates OpenType/CFF fonts to Type 1 fonts, including AFM metrics. You should be able to tell the converter which features to turn on, and have it generate the appropriate character set and ligature and kern specifications.
• Xwrits should be optionally compilable with GNOME/KDE support (probably GNOME). I want a dialog window that lets people graphically set its options.
• Release intrigue: Make a timeline showing when releases of the various packages I distribute came out, to get a handle on how much time I waste.

Graphic note: I recently (February 2002) read Alan Bartram's Five hundred years of book design, a fun illustrated polemic on Famous Books of the Semimillenium by a British designer. Boy is he British: he talks about ``national characteristics''; he savages most every American typographer, overlooking similar faults in fellow-countrymen. He especially despises needless punctuation, like periods, at the end of headings, which was common until the late 1800s. ``Why,'' he seems to ask people three hundred years dead, ``didn't you realize that period was unnecessary?!'' Pleasantly aggravating. I thought I'd include a period in this heading. I couldn't: it looked ridiculous.

Return to Eddie Kohler