Use case 1: Not being forced to use web paradigms
Even with "ajax powered" technologies, the web is still very client/server, stateless and page based. The session state between requests from a single client still has to be minimal and it's usually not (very well) possible to keep persistent/open (database) connections, cursors, large amounts of state and so on. Ajax adds a sort of RPC mechanism in between, but most event handling, for example, has to be handled in the client.
Also, in the end, you still have to write the clientside UI/logic in HTML and javascript.
One of the few alternatives is compiling python/java to clientside code. This is what GWT and Pyjamas do.
RCTK provides a different approach. Applications are long-running processes and keep as much state as they want (just like ordinary desktop applications). They send updates to the UI (which happens to be a browser) whenever they want and handle events from the UI locally in the native language (i.e. Python). This also means that:
- it may be able to "re-attach" to an existing running process. The toolkit keeps track of the entire state of the UI, so it should be able to rebuild it at any point. (not implemented)
- processes can run under different userid's (not implemented)
- processes can keep open connections (i.e. to a database, an IRC server, etc)
- The UI can be designed in a tool like Glade, exported to XML and be build automatically on the clientside (not implemented)
And RCTK application is more like an application running on X11 or possibly some VNC/NoMachine/Citrix remote desktop/application system than a web application.
Even though you're not forced to use Page-based views, MVC, url routing, using sessions, and so on, you're still free to choose any design pattern you like.
Use case 2: Porting existing desktop applications
It should be possible to provide a wxPython or TkInter API on top of rctk, after which you'll be able to expose your existing applications through the web. The RCTK API is actually inspired by TkInter and AWT (Java)
