Re: [Gnumed-devel] web client via pyjamas

[Sebastian Hilbert]

Am Samstag 10 Juli 2010, 14:40:02 schrieb lkcl:
> Sebastian Hilbert wrote:
> > Am Freitag 09 Juli 2010, 23:34:42 schrieb lkcl:
> >> as both SimpleXMLRPCServer and SimpleJSONRPCServer are based on
> >> SimpleCGIServer, which is based on SimpleHTTPServer, you have the
> >> simplicity of:
> >> 
> >> a) doing everything from python.  no apache web server needed
> > 
> > Sounds good. For GNUmed it would need a maximum of 10 clients at a time I
> > would guess.
> 
>  pffh, yeah - then something like the SimpleJSONRPCServer is a fair choice.
> by the time you get to 50+ clients, then you start to need to be a bit more
> concerned.

Good to know. Different from what other FOSS projects seem to advertise we 
target the physicians doing primary care. You rarely have a physician's office 
with 50+ clients connecting at the same time :-)

> 
> Sebastian Hilbert wrote:
> >> b) not having any complex or unnecessary dependencies: django is _huge_
> >> and
> >> the only bits of it you're going to really use is... its ORM!
> > 
> > Not even that I guess. I personally have no interest in rewriting a
> > single line of middleware.
> 
> *lol* surpriiise :)  tackle one thing at a time.
> 
Yep. Exactly.

> so, very simple: you pass _all_ the arguments required to get at the info.
> this was one of the reasons why REST was "invented": it is in recognition
> of this fact.  the "state" information is done in a similar way, by
> storing it in the URL, in a formal manner.
> 
> it has to be pointed out that REGARDLESS of the framework (client OR
> server) that you choose, you WILL have this exact same problem to tackle.
> 
> welcome to web development :)
> 
Good thing you are writing so detailed responses. that way I am slowly 
learning athing or two.

> the only thing which has been sensibly solved (by frameworks) is "login"
> state.  basically these map to cookies on the client-side, and each HTTP
> request (even AJAX ones) is guaranteed to feed the cookies back to the
> server: the server looks up the cookie in some permanent storage (SQL
> usually) and goes "oh yes, i handed that cookie out to someone who
> previously logged in with credentials XYZ, therefore we're going to assume
> that the entire system hasn't been hijacked or sniffed, and we're going to
> trust that cookie as quotes authentication quotes.  so, to be nice to the
> developers, we'll read out the username from the database and shove it into
> a convenient-to-access data structure".
>
Yeah I guess it is the whole cookie stealing thing here ? We could just ask 
the user to provide credentials for every call :-) That would keep them busy.
 
> 
> Sebastian Hilbert wrote:
> >> so there's absolutely no need for any web server like apache, or in fact
> >> any web server framework at all: all you're doing is GET of static
> >> files, POST of multi-part forms and JSONRPC.  _nothing_ else.  no HTML
> >> templates - nothing.
> > 
> > are HMTL template (e.g. cheetah) useful in that case to seperate markup
> > and
> > data or does this concept not apply here ?
> 
> they're not even _remotely_ useful! :) you're not doing dynamic HTML
> generation *at all*, so you do not need any HTML templating.  that's the
> whole point of the pyjamas / GWT approach: you _do_ not do _any_
> server-side "dynnaamick" HTML, period.  _everything's_ done using widgets,
> just like you would with a desktop widget set.
> 
> when you wrote to me last week, i did say that it would be best to forget
> _entirely_ that pyjamas (and GWT) are "web-based", and to treat them
> exactly like you would python-wxWidgets, python-gtk2 or python-qt4, and i
> _really_ meant it :)
>
I am starting to get it :-)

 
> the pyjs-compiled HTML+javascript is entirely static HTML; the data is
> fetched using AJAX (usually JSONRPC is recommended, but there are instances
> where you just use "ordinary" XMLHttpRequest directly, to get static text
> files, static XML, static HTML and so on).
> 
> it's this latter instance where you miiiiight conceivably veeeerrry
> possibly need to create a "dynamic" server-side view which requires HTML
> templating.
I see

> > 
> > That won't happen anytime soon. We are using features that are not
> > supported
> > in MySQL.
> 
> fortunately, all of the three ORMs i recommended support 7+ back-ends:
> postgresql is of course amongst all of them.  so you could conceivably, at
> some convenient point in the future, convert over, still using the exact
> same database, exact same data.
> 
Maybe I am wrong but aren't developers using sqlalchemy to give the user a 
choice ? I mean one could program with sqlalchemy but the only choice would be 
postgresql because the other backends don't provide all features ? I think I 
am missing something here.

Sebastian