Introduction

It might be confusing what RCTK speficially does and how it works, mostly because it can't really be compared to common toolkits/solutions

Terminology

RCTK consists of a number of components. Eventhough you don't need to be aware about what runs where it is a good idea to have a clear definition/naming of these components.

Spruit:

This is the server-side Python toolkit that you will be programming against. Spruit is Dutch for Sprout, and let's just pretend it means something like "Server Python Remote UI Toolkit"

Onion:

This is the browser code that's responsible for drawing controls (using JQuery, at this moment), handling events and forwarding these events to Spruit. Onion in Dutch is 'ui', which sometimes also means user interface.

Bus:

Something I haven't invented a better name for. Everything related to the communication between Spruit and Onion. In its simplest form it's HTTP with json messages, but eventually we also hope to support Comet/Websocket-like communication.

We're open to better suggestions :)

How it works

Unlike most web applications, the application does not run in the browser. The browser (Onion) only maintains the UI state and forwards events (such as button clicks) to the server (Spruit). All code/logic is on the server where the application is running.

Applications are statefull: they keep running between requests. This means that if you close your browser, the application will continue to run. Eventually you should be able to reconnect to the running application again.

RCTK is more like a remote Desktop session or a remote X11 application than a website/web application.

Compilation

No compilation takes place. Unlike GWT and Pyjamas where (a subset of) Java and Python are compiled to Javascript you can use almost any Python feature and Library that's available. Python 3 support should also be feasible.

Client / Server separation

RCTK doesn't make an explicit distinction between client and server in its API's. Eventhough the UI will run remotely on a (possibly) different machine, RCTK treats it as a local display. As a programmer you don't have to worry about what is happening where.

Because RCTK treats everything as being local, you can simply open database connections as you are used to in non-web Python application, keep resultsets and counters in memory, and so on. If you want to update something in the UI, just ask RCTK to do it for you.

Eventhandlers are also compeltely local. Consider the following tiny RCTK program:

class Counter(object):
    def __init__(self):
        self.counter = 0

    def click_handler(self, event):
        self.counter += 1
        if self.counter == 1:
            self.message.text = "%d click" % self.counter
        else:
            self.message.text = "%d clicks" % self.counter

    def build(self, tk, parent):
        parent.setLayout(Grid(columns=2))

        button = Button(tk, "Click me")
        self.message = StaticText(tk, "0 clicks")

        button.click = self.click_handler

        parent.append(self.message)
        parent.append(button)

As you can see, you create some controls, install a handler and define a local handler that handles the updating. No Ajax, HTML, CSS or javascript needed. By updating the 'text' attribute on 'self.message', which is a StaticText control, you instruct RCTK to update the UI.

Performance

RCTK does not do any heavy computation in the browser, but the UI itself and the individual controls may be complex, partially because RCTK makes it easy to build complex user interfaces.

The server side library (Spruit) is relatively lightweight and should even be able to run on embedded devices (if they run Python). There's no dependency on display servers (i.e. Xserver, VNC, NX) or heavy UI toolkits (gtk, Cocoa, wxWidgets, and so on).

However, because RCTK applications are statefull, each user will have their own process running on the server. This means RCTK won't scale well for massive amounts of concurrent users (on a single system) or anonymous websites.

It's also possible to run multiple applications in a single process which makes RCTK suitable for simpler, lightweight applications such as questionaires.