On Tue, Feb 25, 2003 at 01:20:34PM -0600, Ian Bicking wrote:
| On Tue, 2003-02-25 at 11:51, Clark C. Evans wrote:
| >   Transaction  - created for each http incoming request and
| >                  its response (thread safe storage); in Twisted this 
| >                  is just "request"
| > 
| >   Servlet      - a singleton created once (but not thread safe, 
| >                  but items shared across all transactions); in 
| >                  twisted this is a "resource"
| 
| I'm not clear how this would work.  If the servlet isn't threadsafe, how
| can the application be threaded?  Are you proposing a model more like
| HTTPServlet, less like Page?  Thread safety just seems like a burden to
| me -- if you want to share resources module globals or class variables
| are just as easy, and since it's not threadsafe you can also use
| instance variables.

Hello Ian.  I just see that there are two "storage" requirements:
  (1) I need to store information specific to the given request; and
  (2) I need to store information shared by all requests

In the Twisted model, the Resource/Servlet satisfies #2, and the
Request/Transaction satisfies #1.  So, really, I don't need any other
objects.  The Resource may have multiple threads running in it
at any given time; while the Request won't.

In Webware, you have an additional Page object, which can have
more than one instance (unlike Resource) but acts as thread-local
storage.  In my current application I'm always confused as to 
if my request-specific information should be tagged onto the
request or onto the Page.   I've determined that storing 
information in Page isn't great... beacuse you have to "clean up"
after yourself.  Storing information in Request is simpler.
Further, since Page can have multiple instances, i must use 
module-level variables for data shared by all resources.  

I guess the advantage of Page is that you don't have to pass
around the request as the first argument to things.  But really,
that seems a bit excessive.   If someone *really* wants this
notational convience, it could be implemented as a "wrapper" 
to the request.   So, in short, Webware adds a Page abstraction, 
with the notion that it isn't a singleton and can be put to sleep()
but I really don't see any advantage that this extra complexity
over just storing what you need in the Request object.

Please don't take this negatively.  Webware is just awesome product
and without it I wouldn't have put together my application in as
short as time as it took!  Further, Webware has been rock solid.

| > Does that work?  I tried it once or twice and gave up about a 
| > year ago...
| 
| Yes, I added support less than a year ago (a couple months ago I
| think).  If you look at WebKit/HTTPServer.py, it implements one
| example.  There still isn't real support for non-HTTP requests (though
| you can fudge and shove other requests into HTTPRequest).  That's
| probably fairly easy to fix.  There's also an underlying assumption that
| transactions are more-or-less stateless, like HTTP.

Neat. 

Clark


-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss

Reply via email to