Planet SoC

I’d like to apologize for two things:

1. For not posting to my blog in so long.
2. For not continuing the distutils discussion.  I’d kind of abandoned the idea for using distutils to distribute my app, but might end up using it to package my gateway, so stay tuned.

With that said, I think it’s time for me to share my views on the subject of what a good Kamaelia component is.  Some of these are general rules of thumb of computer science, but they bear repeating here too.  So here it goes.  My rules for writing good Kamaelia components:

In the past few days, I’ve grown a lot more familiar with python’s packaging options than I ever hoped to become. So, I thought I would share some of the things I learned in case anyone else runs across a need to use this in their GSoC projects (or any other project for that matter).
The setup script
This is the meat of python distutils. Surprisingly, there’s really not all to writing the setup.py script itself. Suppose I have a file called “foo.py” that I’d like to install on someone’s computer. Here’s what a setup.py script will look like: (examples shamelessly copied from the distutils documentation)

You may download the initial version of Kamaelia Publish here (Mac OS X only currently). Upon installing the package, you will find that Kamaelia Publish can serve basic WSGI webpages. You will get a demonstration of basic WSGI functions by going to http://127.0.0.1:8082/simple.  I’ve gotten it running using MoinMoin, but for some reason POST methods don’t seem to work (thus you can’t edit pages).
And yes, I know the fact that the icon keeps bouncing up and down in the dock is annoying.  I’ll have to find a way to fix it.

It’s been far too long since the last post (exams looming large over my otherwise peaceful existence), and given that my fellow SoCers have managed it I think it must be time for a status update. Firstly (and perhaps most importantly) we have sound! The screenshot below shows pygame drawing a bouncy XY pad, all created as a Kamaelia component. This is then outputting OSC messages which are read by PD and used to trigger and modulate percussive noise.

I just thought I’d make a post about some of the miscellaneous goings on inside the Kamaelia project.

In response to a blog post over at Ye Olde Clue. I thought I’d write up my thoughts on this topic since I’m (hopefully) going to try to review this code and merge it into the core of Kamaelia. I say hopefully because it’s partly a matter of experience with subversion which at the minute I’m a few years behind other people on the Kamaelia project. Fortunately they’re all patient with me while I ask questions.
Okay, so, meanwhile back at the point: “Where should Multicore support sit in the Kamaelia tree?”

It’s been a little while since I’ve posted last, and there’s a lot that’s new, so I’ll enumerate the points:

Ok, so this is one issue that’s been bugging me about HTTP. I keep hearing the acronyms URI and URL mentioned. I knew that URL wasn’t technically accurate, but I couldn’t ever find a good explanation of what the difference between the two are or why URI is more technically accurate. This is even after reading various explanations about the subject. Here’s what I’ve come up with:
URI
A URI is a name that identifies something globally. Admittedly, this explanation is a little bit vague, but then again the idea of a URI is kind of a vague concept. We’ll come back to this later, but I’ll give you a few examples of URIs:

Kamaelia: The future of Python frameworks looks promising
Gloria from DevChix writes about Kamaelia. It is nice to see that the project is gaining some attention from others. Gloria does bring up one important point though: installing some of the dependencies for Kamaelia is a pain. Especially if you’re a newbie. Hell, sometimes even if you’re not a newbie.
I would like to point out that to me, this really seems like more of a python issue than a Kamaelia one. I mean, try installing Eric or SPE without some kind of package manager. You’ll quickly learn the meaning of the words “dependency hell.”

Ars Technica writes about Google’s upcoming FriendConnect technology. From what I can see, it looks pretty awesome. It is essentially an extension of Google’s OpenSocial that allows site owners to embed authentication and various other social apps in their webpage. They give Ingrid Michaelson’s website as an example of what FriendConnect can do. Whatever the case, it looks pretty interesting. And more importantly, it looks like something I would want to put into Kamaelia Publish. I just signed up for a preview release of it. We’ll see if I get in.