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. -- http://mail.python.org/mailman/listinfo/python-list
