Future standard GUI library

[Carlos Nepomuceno]

----------------------------------------
> From: feliphil at gmx.net
> Subject: Re: Future standard GUI library
> Date: Tue, 28 May 2013 19:26:55 +0200
> To: python-list at python.org
>
>> Please give me an example of a "suitable transport layer for a RPC
>> protocol".
>
> I won't give you an example, but just some very basic criteria:
>
> - It must be very efficient for very small "datagrams"

Interoperability is much more expensive than efficiency. That's why you won't get the most optimized protocol for speed or size.

> - It must provide connections

What do you mean?

> - For asynchronous programming it must provide for callbacks
> No RPC-over-HTTP protocol that I know of does this.

XHR implements asynchronous callbacks over HTTP.

> Besides, no one needs RPC just to logically separate GUI and
> application layer. And between application logic and database, you use
> the native database API for the RDBMS in question, of course.
>
> The whole idea to centralise application logic (and even the GUI with
> "web applications") is backwards, it dates from the 70s/early 80s when
> desktop computers weren't able to run application logic. Today, to make
> an application responsive (minimise latencies and maximise throughput),
> it's just obvious to *de*-centralise as much as possible. In fact,
> if Postgres-R was available for production, you could even distribute
> the persistence and run an entirely "serverless" application.

"web applications" is so nowadays! All of my recent software development projects (last 10 years) focus on business processes integration.
In all of them the BLL (Business Logic Layer), or "application logic", is run on server side (as a controller in MVC) due to security and performance reasons.
None of my clients want their business rules and internal workflows exposed, so the old ways of the 70/80's ain't gonna change.

> Sincerely,
>
> Wolfgang
> --
> http://mail.python.org/mailman/listinfo/python-list