[Gnumed-devel] choice of web frameworks

[Luke Kenneth Casson Leighton]

many apologies i'm having to reply using digest, not nabble, nabble is
down right now.

>> > One thing I still not fully comprehend is the asynchronous parts of a web
>> > interface. But I have been told that AJAX can also be synchronous. I
>> > currently have not enough knowledge on that part.
>>
>> Yes, it can be synchronous. google "comet"

 synchronous AJAX causes problems.  browsers can only have two
outstanding HTTP requests at a time to a server, in order not to
"overload" MS IIS servers basically :)  the problem is that with only
two outstanding, if one of them is a "comet" connection - pretty much
permanently on - that leaves only one left, and the application's
interactivity / performance degrades.



> I guess for an in praxis setting (50 clients max) I was looking for this
> ---------------------------------------------------------------------------------------
>
> optional client side framework for dynamic content
> (pyjamas or js framework)
>  |
> webbrowser (displaying html)
>  |
> webserver (e.g. cherrypy)
>  |
> gmPG2
>  |
> psycopg2
>  |
> PG
>
>
> I guess what I don't have in mind is
> ----------------------------------------------
>
> optional client side framework
>  |
> webbrowser
>  |
> django orm
>  |
> PG

 you cannot do this, and that's the end of it.  ok, you could, but
you'll need to redesign django's ORM and most of django with it.

 the reason is this:

 *the current wxPython database connection is persistent, and it uses
a username+pass with roles and access control provided by postgres.
it's a state-ful connection.

 * the HTTP protocol is STATELESS.  browser makes a connection, grabs
some stuff, buggers off and probably never comes back again.

most web servers and most web frameworks, "state" revolves around
"Cookies" - cookies are the only thing (almost) that can be used to
uniquely identify returning visitors (there are other tricks, such as
unique URLs per user, adding unique info to all GET and POST args and
so on but they are very intrusive: cookies are non-intrusive).

the process is as follows:

* browser connects for the first time
* server creates a cookie, stores the cookie in a SQL session table
* server sends response (including cookie)
* browser connects again (sending back cookie)
* server looks up cookie in SQL session table
* server now knows visitor is unique
* server can do more SQL lookups based on visitor's ID
* server sends response (including same cookie)

do you see where the problem is with this, compared to what _you_ want
to do?  it's _right_ back at the 2nd step "stores cookie in SQL
session table"

which SQL table?

and... what username and password are going to be used to connect to
the database, eh?

you certainly can't use the postgres username/pass because this is the
_very_ first time that the browser is connecting.  they haven't even
been given a login page, to sign in to, yet.

so... how about a global username/password?  ok, _great_.  now when
the user comes to log in, which of the two database connections are
you going to use?  the global one or the personal one?

it gets worse.

where _exactly_ in memory of the server are you going to keep this
persistent database connection open?

given that the HTTP protocol is stateless, most web server frameworks
revolve around the idea that threads are totally interchangeable, that
all application state revolves around the _database_ (once you have
got that session id out of the cookie).

so, one thread could be doing one user one moment, and then next query
the exact same thread is used for a totally different user, because
the session id it was handed by the framework was totally different.

do you see what the problem is?


> Am Sonntag 11 Juli 2010, 22:59:52 schrieb lkcl:
>> ok try this:
>>
>> http://lkcl.net/gnumed/0001-jsonrpc-cherrypy-test.patch
>>  so, one on the TODO list for you already: solve the psycopg2 problem, or
>> find a better framework.
>>

> Will do that today. The use of cherrypy has by far not been an educated
> choice.

 ordinarily, it would be a good one.

as explained above, the fact that you're using postgres "roles" to do
security is going to competely **** up your options.

 every single web framework that i know of you _do not_ do per-user
database password connections: there is a _global_ config file in
which the database username and password are stored, and all
role-based security/decisions are totally reimplemented in the web
framework itself.   zope is the classic example.

 so the framework is going to have to be an extremely esoteric one -
one that is capable of maintaining persistent database connections on
a per-session basis.

 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.

this scenario _doesn't_ scale, because if things go wrong (such as
users connecting to the login page repeatedly with cookies switched
off, keeping on trying because the cookie isn't returned by the
browser) you could end up running the server out of resources as it
keeps creating more and more persistent threads that never get used,
because the cookie is the only way to associate the stateless HTTP
connection with the persistent thread.

so, in this rather dangerous scenario, you will be able to have the
gmPG2 persistent connection actually continuously running.

 it turns out that i actually need exactly such a web framework, for
two other projects.

 if however you find something that can already cope with this type of
situation - and you will _really_ have to ask around and explain
_really_ clearly what it is that you need - please let me know.  about
the only framework that _might_ be capable is twisted.  but... twisted
has that name for good reasons!

 whomever you speak to, please bear in mind that what you're asking
for is definitely non-standard practice, and is pushing the limits of
web server framework technology.

anyway. in the meantime i'll be hacking up some code :)

 l.