Re: [Gnumed-devel] choice of web frameworks

[lkcl]

> I am not sure I fully comprehend this. Could you please explain why a
global 
> and a personal connection is needed ?

 ok.  the personal connection is to do personal private secure restricted
per-user access, yes?  roles play a part, access is denied based on the
role.

 so... um... when a browser connects - bearing in mind that you have
ABSOLUTELY no prior knowledge of whether they have or have not connected
before, if ever (because HTTP is "stateless") - under what user credentials
are you going to connect to the database as, in order to ascertain from the
cookie whether there is a session outstanding, when the session information
is stored.... in the database!

 for that purpose, you can't use any of the other personal private secure
restricted per-user connections, can you?

 but, until you've determined what the user is (from the session cookie),
you can't safely decide which one of those per-user connections to actually
use to serve the data!

 catch-22.

> >  i.e. _even though_ the user may never come back again, and _even
> > though_ the HTTP protocol is stateless, a thread or process has to be
> > created on the server which DOES NOT DIE, to which the user's browser
> > can be continuously, persistently and securely reconnected.
> >
 
> That was what I was thinking. But you are telling me that this is not the
> way 
> the web works.
 
 correct.  it's not _normally_ the way that web services are written,
because normally you either have a global persistent database connection
(used by all threads) or, more likely, you *reconnect* to the database on
every single damn request.  but in each case, you *never* use "personal
per-user credentials", you *always* use "global database credentials".

 i say always, but there's always an exception :)

> Guess that is true. Maybe the cookies off situation can be detected and no 
> connection is attempted as long as cookies are off ? :-)

 yep - you got it.

> Now that is interesting. You say that is not the way it works yet despite
> the 
> fact that you seem to know what you want/need you are telling me that you
> need 
> this for two of your projects ?

 *sigh* yes.  one is to extend rtmplite to do HTTP and HTTPS.  rtmplite uses
something called multitask.py to do _single process_ multitasking and can
serve multiple RTMP clients from a single process.  the end-result is that
it is incredibly easy to pass real-time video/audio stream data between the
clients, without having to do shared memory, unix domain sockets, blah blah,
all that's gone because everything's in one process.

 the second is to do pyjamas-web which is a web service where you can run
pyjamas applications *server side* and the server will generate HTML.  the
problem comes if you use a "standard" web framework: when you click a
button, and the python application got dumped because it was in another
thread, when the thread ended, the pyjamas app got thrown away.  browser
comes back with the button-press response, whoop, app regenerated, back at
the first page!

 so by actually having again a single-process and using cookie-tracking it's
possible to store the pyjamas app in-memory, such that when the button-press
comes in, the correct in-memory running instance, with a shit-load of state
in in, can be correctly accessed.

the alternative would be to serialise the entire pyjamas app on-disk (or to
SQL db) which i gave serious consideration to, but... naah.  it's actually
kinder on the environment to just keep the app in memory :)

so, yah.  three different apps, all needing one of the most seriously obtuse
bit of coding evahh :)

i'm sure it's been done before, but can i find it?? pffh.

l.

-- 
View this message in context: 
http://old.nabble.com/Re%3A--Gnumed-devel--choice-of-web-frameworks-tp29137242p29137242.html
Sent from the GnuMed - Dev mailing list archive at Nabble.com.