BBX Python: Next Steps

User Interfaces

Rob Paskowitz is taking a stab at hooking up the Qt port through the LGPL PySide bindings.

There's also an SDL port, so getting Pygame running is a definite possibility.

Another step for Flash-loving people would be to use an ANE layer from an AIR app replacing the Python launcher, so that a Flash user interface could be hooked to "back-end" business logic written in Python. May sound crazy to some people, but from a testability point of view, Python is potentially unmatched, while from a UI point of view Flash has a lot of things working for it.

I'm personally not highly concerned about the UI, partly because I can leave that to others, partly because I have some confidence we'll eventually see RIM release their PyCascadesSDK package (presumably layered on Qt as well) and the issue will be moot, and partly because I'm better at the plumbing...

The Plumbing

One idea I have is to simplify the "native stub" launcher code so that it doesn't even bother with initializing anything aside from Python. Maybe it would still have to do a bps_initialize() and a few basics, but I could skip the screen stuff. It would invoke a Python script named probably in an environment variable (specified in MANIFEST.MF), and that's it. Anything else would be done through libraries, from Python.

Doing this would allow me to prepare a simple app packager, which would itself be in Python, which would combine the native stub, the Python code, and a generated MANIFEST.MF file together into a .bar file which would be a complete self-contained app. For now it could rely on having one of the other SDKs installed (Native, AIR, or WebWorks) for the code-signing capability, but aside from that it appears possible to do already. A couple of the required entries in a MANIFEST.MF file appear to be "opaque" hashes of some kind (the short ones like Package-Version-Id) but I believe those could be reverse-engineered if necessary, and the rest is straight-forward. (If you have any knowledge of those hashes, aside from the obvious SHA512 ones, please let me know.)

Third-Party Native Extensions

While any 3.2-compatible pure Python packages will work perfectly and without change in this environment, there are also many interesting third-party libraries which include some native code. While I expect many of them will work without much problem, there's still a need to compile them with the NDK to make binaries available, and to test them out. First one I'd like to see, personally, is Greenlet though I don't even see that they've built it for Python 3.2 yet.

We might also just want to start compiling a list in the repository's wiki (which anyone with a free bitbucket account can edit). Which such packages would provide functionality that would really add value on the PlayBook? Which won't work that well, because of memory requirements, performance issues, or maybe other dependencies that aren't yet supported under Python 3.2?

Documentation

There's hardly enough here yet to document, but if there's one thing that's been the downfall of many an otherwise-promising open source project, it's documentation. I noticed I'm already short one key thing: a license! For the record, I'm planning on using MIT [2] or maybe BSD [3] unless there's a good reason to use something else (such as, maybe RIM insists on Apache 2.0, as I want to keep this compatible with their plans).

I think I've made a reasonable start already, for a project that's only four days old! Still, what I think needs to be documented isn't the same as what some other people think needs to be documented. Are you being held back from participating because something's missing? What is it?

BBX-specific Packages

This one is an interesting area. RIM's already got a whole batch of libraries in the 2.0 beta, with no major issues seen yet with any of them. They're wholly unsupported, of course, and as I've mentioned earlier we've got no guarantee that RIM will continue to expose these for us to use. Here's a few of the packages available so far:

Those were presumably written to be used by RIM's own code, however, and third-party apps may have other needs. Packages could be written to add useful new functionality. One option is to use the ctypes module to wrap existing dynamically loaded (shared) libraries (.so files). This is relatively straightforward if you have the header file for the library, and provides a very quick way to expose native functionality to Python. You could do useful work in this area if you know C well, even if you're just starting to learn Python.

Get Involved!

This project represents a real frontier for hackers (in the old-style meaning of the term: those who find cool ways to make technology behave). The PlayBook is being revealed as an awesome and versatile platform, and will be an excellent place for high-performance [4] Python programs to run as apps. Now's a good time to get involved, so you can have a direct influence on the direction this initiative will take.

Footnotes: