Re: [Gnumed-devel] web client via pyjamas

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


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.

the only "concern" that there is is over state information: specifically,
logins.  jsonrpc is, like pretty much every single RPC system except for the
really good ones such as DCE/RPC, entirely "stateless".  as web services are
also stateless, the thought of extending jsonrpc to include references to
data structures that have been stored on the server, ready for a _second_
jsonrpc function call to access in the future... complete nightmare.

basically what i'm saying is that every jsonrpc function call pretty much
has to include alllllll the parameters needed to access the data: you
_cannot_ expect the server to store "state" for you.

so in that fontforge jsonrpc service i wrote, it goes like this:

def get_font_info(self):
    return {'name': self.current_font.name, 'num_glyphs':
len(self.current_font.glyphs)) }

def get_glyph_info(self, glyph_name):
     return {'glyphname': self.current_font.glyphs[glyph_name] .... }

def get_glyph_contour_info(self, glyph_name, contour_idx):
    return {'contour_name':
self.current_font.glyphs[glyph_name].contours[contour_idx] ... }

def get_glyph_contour_points_info(self, glyph_name, contour_idx, point_idx)
:


 you get the idea, i am sure.  you *cannot* pass a "reference" over a
JSONRPC service boundary without getting into some horrendously overcomplex
programming, involving storage of "state" into SQL tables, for consistency
(or some other web-service-globally-accessible storage).

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 :)

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

this is what django does, for example: the request object which gets passed
to every single function in the application _will_ have a "request.session"
object, and if you install django-openid for example that request object
also has "request.openid" and so on.


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 :)

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.

one extreme case that i used was dynamic generation of the CSS files.  i
wanted users to be able to choose the background colour of the web app:
normally the CSS file is static.  but, i made it a target of the django
framework (a view) i was using at the time, and used standard django
templates to read out the colour from the SQL database, associated with the
user's preferences.

for GNUmed, however, i cannot conceive of even a single instance where you
would want to combine HTML templates with the data coming back from JSONRPC
responses, and i cannot conceive of a single instance where you would want
to "dynamicise" the static HTML/CSS/JS created by the pyjs compiler.

data coming from JSONRPC is in terms of float, int, list, dict, classes
(using "__jsonclass__" hints as they're called) and None.

it's _not_ in terms of "uh bi' ov aitch tee em eww"

:)


Sebastian Hilbert wrote:
> 
>  what's neat about writing unit tests is that _later_ you can convert away
>> from psycopg and use sqlalchemy, sqlobject or even django's ORM (because
>> of
>> the features offered by django south i seriously strongly recommend it).
>> 
> 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.

l.
-- 
View this message in context: 
http://old.nabble.com/web-client-via-pyjamas-tp24343193p29125827.html
Sent from the GnuMed - Dev mailing list archive at Nabble.com.