Future standard GUI library

[Michael Torrie]

On 05/26/2013 11:43 AM, Wolfgang Keller wrote:
> And just like HTML never was a valid GUI framework and never will be
> one, HTTP will never be a suitable transport layer for a RPC protocol.

On good thing web development has brought us is the knowledge that
modularization and layers are a brilliant idea.  Your back end exposes
services and business logic, and your front end can be in HTMLv5 and
Javascript, or QtQuick, PyGTK, or Visual Studio.  If you do need a
native interface, it's a heck of a lot easier to rewrite just the
frontend then the entire stack.  Who cares how the RPC is done; that's
an implementation detail.  HTTP does happen to work well though.  Why do
you say it is not suitable?

> From the description this looks like a simble database CRUD
> application. Somethign like that is definitely easier to implement and
> to deploy and a *lot* more functional with any of the RAD frameworks
> available for Python.

Chuckle.  Simple CRUD, eh.  Almost all apps involve database CRUD
interactions.  And often in highly complex ways using business logic.

Maybe it would have been faster to develop, but ultimately less useful
and require more development time in the long run.  suppose I now want
the app natively on my phone (because that's all the rage).  It's an
iPhone.  Oh.  Apple doesn't support Python.  Okay, rewrite the works,
including business logic, in Objective C.  Now I want it on my android
phone.  Oops rewrite the stack again in Java.

Since his application by nature is network oriented (client/server I
presume since he mentions multiple users), sticking it on a web server
and having the front end be separate (be it HTML or not) gives him the
flexibility to rapidly build native "screenable" UIs for his app on any
platform he chooses, something your philosophy does not allow for.