Opened 14 years ago
Closed 13 years ago
#152 closed enhancement (wontfix)
configure flappserver apps with .tac file?
Reported by: | Brian Warner | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | usability | Version: | 0.4.1 |
Keywords: | Cc: |
Description (last modified by )
It might be easier and more flexible to configure the flappserver's applications by writing out a .tac-like file (which instantiates a Service and assigns it to a well-known variable), rather than our current practice of writing a series of lines (including one repr()
of a tuple) out to a text file. At least it would be easier to read the resulting file, so that when you look at an existing flappserver, you can figure out what it was supposed to do.
The app setup code should have a chance to do some work at "flappserver add" time, in particular to capture the cwd and file-permission mode, and to validate the arguments somewhat. But the later app-instantiation code should also get to do some work: upgrades to the code should not always require re-adding the app. So I'm not sure what exactly should be written into the .tac file: a literal argv array, a JSON dictionary of semi-processed arguments, or a pickled usage.Options instance. It may be sufficient to just write key=value pairs into the file, instead of positional arguments.
I'd also like to think about plugins here: how much work is necessary to start using a new app type (one which does not ship with foolscap)? The app directory could contain an .egg file, or the appserver could have a shared directory that is always added to PYTHONPATH.
Change History (2)
comment:1 Changed 14 years ago by
comment:2 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
yeah, .tac is bad. Another ticket can consider changing the format of the static data used to configure the flappserver.
OTOH, we're actively trying to move *away* from .tac files in Tahoe, since they require hard-coding a classname into the file, which then makes compatibility/upgrade more difficult in the future. Maybe an .ini-style file (with a 'type' keyword to replace the classname) would be easy-to-read and capture the necessary information.