Re: [Gnumed-devel] choice of web frameworks

[Sebastian Hilbert]

Am Montag 12 Juli 2010, 13:58:49 schrieb Luke Kenneth Casson Leighton:
> many apologies i'm having to reply using digest, not nabble, nabble is
> down right now.

Don't worry.

> 
> >> > 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 am learning quite a bit here and I am enjoying the technical discussion. I 
really start to doubt that all this is being considered by any of the other 
EMR but I am always here to be proven wrong. 

My point is that unless this discussion here has taken place chances are good 
you will play framework-switcheroo to the end of days. I am not calling names.

> > 
> > 
> > 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.
>
Forget about django. We have no code relating to it anyway and I specifically 
said that I was researching the esoteric solution. I am not against 
implementing this by using django. That is up to the person actually writing 
the code. I am interested in discussing the pros and cons which we are doing 
nicely here.


>  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).
> 
While this might be obvious to web developers I doubt it is obvious to 
everyone so this is important information.

> 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?
> 
I am not sure I fully comprehend this. Could you please explain why a global 
and a personal connection is needed ?

> 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?
> 
No. But hopefully after I reread that a couple of times I will see the 
problem.

> 
>  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.
> 
I lack the knowledger to fully understand the implications.

>  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.
> 
I see. 

>  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.
> 
Seems like it.

>  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.

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

> 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.
> 
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 ?

>  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.
> 
This is exactly the reason we are here. If We wanted some sort of weekend job 
/ I don't care about security type EMR we could have done it differently. 

We don't want that. If it takes pushing the limits so be it.

> anyway. in the meantime i'll be hacking up some code :)
> 
That I like to hear. Many times this ends in name calling but noone ever hacks 
any code.

Sebastian