[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] choice of web frameworks
Re: [Gnumed-devel] choice of web frameworks
Mon, 12 Jul 2010 17:13:32 +0200
KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.5; i686; ; )
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.
> >> > 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
> 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
> 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.
> 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