Jeff Watkins wrote:
I currently have the following interface:
def start_extension():
pass
def shutdown_extension():
pass
def create_extension_model():
pass
Simply for the sake of discussion, I will offer up how Paste Deploy
works in this case, as I think it is addressing the same issue.
In Paste Deploy these extensions are typically written as middleware.
That means that they act as applications, and get first shot at the
request (but typically pass the request on to the next level in the stack).
So, for instance, authentication middleware works by inspecting the
request and setting REMOTE_USER. It could also create a user object and
put it in some key in the environment, say 'turbogears.user'. It gets
its own section in the configuration file, and its own configuration.
The middleware can watch the response -- say, for a 401 response
(indicating that a login is desired), and rewrite that (say, to a login
screen). Or, the other way around, it can see links coming in and
intercept them, say providing its own interface at /login.
It's more controlled than the proposed interface, because pieces
underneath the middleware generally opt-in, or any communication is in
the form of the request itself. There's no monkeypatching, while in
contrast the start/shutdown/create interface can only function through
monkeypatching.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
