[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] choice of web frameworks

From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] choice of web frameworks
Date: Tue, 13 Jul 2010 08:30:06 +0200
User-agent: KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.5; i686; ; )

Am Montag 12 Juli 2010, 22:44:55 schrieb lkcl:
> rrrright.  i have at least a beginning:
> git clone git://
> there are at present no other dependencies: is included.
> basically it's a single-process server, bit messy because i haven't hacked
> out half of the RTMP stuff from it yet, but it handles multiple HTTP
> requests, includes doing keep-alives that actually work, and there is a
> demo which will browse the current working directory as a simple http
> server (based on, surpriise
> a session cookie is automatically added, which is used as a lookup to find
> the in-memory app.
> merging this with, and adding in a persistent
> psycopg connection into the "client", this would be ready to use _now_.
> but, you would only be able to use about 2 clients because of the pool
> limiting on the gmPG2 code.

I have to find out what that limit actually means. If I got that right it 
means this that for each client we would need to open one connection. All 
calls to the database would then however be pooled through the gmPG pooling of 
that client or do we still have to open one connection per request ?

Since we support more then one fat client (each haaving its own connection) I 
guess serving 10 clients (10 connections) should not be a problem.

That still does not solve the problem that clients could open up threads and 
bring down the server, doesn't it ? Is there some sort of keepalive mechanism. 
The server and the user's browser would exchange alive information? If a 
browser is closed or if a user navigates away (out of the webapp) in the 
browser no response can be retrieved from the client (which is not there 
anymore) and the thread can be closed after a timeout.

> so, when i talked about looking up the session cookie id in a database
> (using global database credentials) that's all gone, because every single
> session is now stored in ONE process, in memory.  so, a single dictionary
> can be used!  hooraaay.
You see it can be done :-) Pushing the limits of webapps.

> this is utterly crazed, you do realise - but it will actually work.
I don't care if it's novel or crazy. It needs to make sense, work and be 

> i will add jsonrpc next, just for fits and giggles.  have to put in doPOST
> copied from SimpleCGIServer.
Great. What is your long term goal with your solution. Do you plan on making 
it available as a viable solution or just a testbed ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]