[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 03:39 PM 1/30/04 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 03:14 PM 1/30/04 -0600, Ian Bicking wrote:
>>
>>>Sessions remain the use case I consider to be unresolved.  I think 
>>>sessions should be possible to implement portable, without requiring 
>>>configuration that specifies the gateway's process/concurrency model. 
>>>(That doesn't rule out configuration, just that in the absence we should 
>>>be able to pick the right implementation)
>>>
>>>Probably all this requires is a way to indicate the process model.
>>
>>How about by indicating whether the application can be
>>1. Run in multiple processes
>>2. Run by multiple threads
>>as information exposed by the app?  Or do you think that we should have a 
>>"setup" method called by the container to tell the app what model it's 
>>going to be run under?
>
>Yes, I think we need a setup call.  I want the app to be able to respond 
>to the environment, not merely indicate compatibility.  Compatibility can 
>then be asserted by throwing an exception if you use the application in an 
>inappropriate container.

So far, it seems to me that this could be done with the two pieces of 
information mentioned above.  That is, whether the app will (potentially) 
be run in multiple processes, and whether it will (potentially) be run in 
multiple threads.  If the conditions are unacceptable to the service, it 
should raise an error immediately upon receipt of this information.

Note that this means that in the case of very primitive containers, an 
application integrator can themselves invoke the service's setup method.

For "forward compatibility", I'm guessing the setup method should look 
something like:

     def setup(self, multiprocess=True, multithread=False, **futureOptions):

...and the gateway *must* use keywords to supply all arguments, now and in 
the future.  In the trivial case, a service could simply implement:

     def setup(self, **dontCareAboutAnyofThis):
         pass

and be done with it.   Most of my apps will probably just look like:

     def setup(self, multiprocess=True, multithread=False, **futureOptions):
         if multithread:
             raise NotImplementedError("Threads are evil!")

:)



>Either way we have to specify clearly what the models are.

Nobody's yet pointed out anything besides multiprocessness and 
multithreadedness as aspects of the models, so I guess we're done.

We've also managed to rule out some of the hairier multithreading models by 
requiring all locking and object pooling to be on the service side, and all 
thread pooling to occur on the gateway side.

That is, the gateway is responsible for having threads to call runCGI() 
in.  The runCGI() method is responsible for either having separate objects 
per thread, or locking the objects that it operates on.  (Assuming, of 
course, that it hasn't vetoed operation in a multithreaded environment.)

Also, we should clarify that the 'multithread' flag means that the 
service's 'runCGI()' method may be called from more than one thread at the 
same time.  If a gateway uses multiple threads but can guarantee that only 
one will ever call that object's 'runCGI()' method at a given point, it 
should be free to tell the service that 'multithread=False'.  (I'm assuming 
here that there may be multi-app/multi-service containers at some point, 
that can be configured to run some apps serially, and others in parallel, 
according to the needs of the application.)


>>>Yes, my point was just that Twisted .rpy scripts and the like wouldn't 
>>>fit into the model.  Or, they could, but it would be kind of silly, 
>>>since you'd loose all the advantages of async, even if you ran under a 
>>>Twisted gateway.  In contrast, many other systems could be composed into 
>>>gateway and application without any real downside.
>>
>>Right.  The goal for WSGI in the case of Twisted is to let people migrate 
>>apps *to* Twisted, not *from* it.  :)  I don't think that migrating from 
>>Twisted to anything other than another event-driven framework (e.g. 
>>peak.events) is even possible, and there aren't any mature alternatives 
>>with comparable capabilities to Twisted at the moment, if i understand 
>>correctly.
>
>In the scope of web applications Medusa is very similar, isn't it? Fairly 
>significant applications are written with Medusa and without any threads 
>(PyDS, for instance).  But that's an aside.

I was referring to the full scope of functionality that Twisted 
encompasses, such as GUI apps, distributed objects, etc.  Not merely the 
multi-protocol network services part of Twisted.