Google Summer Of Code 2007Kamaelia has been accepted into Google's Summer of Code 2007, so we're very pleased to hear what projects you would like to do. The project list is at the bottom of the page, however please also read these guidelines first.
What is Kamaelia?Well, let's answer this 4 ways.
Kamaelia's aim is to make highly concurrent systems natural to create and simple to maintain. (given a choice of forces the we choose the latter) We seem to be having some success in this and have a number of systems we've built using Kamaelia.
What Sort of Person We Looking For?We're looking for enthusiastic people to work on specific projects, which are listed on our projects pages (to appear shortly) You don't necessarily need lots of experience, indeed we've found a naivete can actually help since you have less preconceptions about how code should be written (And often more open to the component approach).
What we do expect from you though is a very clear interest in the project your doing as part of Kamaelia, and it must fit in with Kamaelia, or some other open source BBC Research project where there is a suitable mentor.
We Want Code We Can UseIn practical terms this means that we want to be able to put your code into the distribution for people to be able to use. This means printing out and signing a contributor agreement. Our contributor agreement is based on Python's, since our project is largely python based. What does this mean?
What we will expect of you
Feedback!This is a wiki page. It uses dojotoolkit so you can edit this page an add your own ideas here, but please don't edit the text above!
Ideas!Fleshing out now:
A file handle like interface to backgrounded Kamaelia componentsThis would enable traditional, non-kamaelia-component oriented systems to use the facilities of Kamaelia components in a manner similar to that of a filehandle, crossed with a dictionary.
A user would be able to do something like this:
from kamaelia.background import background, likefile
In terms of context, this is a wishlist item for syntactic sugar to allow this sort of ability. The key thing is what's happening here.
This takes inspiration from the fact that a traditional filehandle actually abstracts away the fact that the operating system file handling can be quite complex, and writing of data to finally disk (for example) can happen after your programme has exitted. To you however, the operation appears simple.
The key benefit of this is that it will simplify embedding & using kamaelia components in non-kamaelia based systems.
Extend & make more user friendly the Kamaelia Web ServerThe key intent here behind this project is to take the Kamaelia web server, written as a by product of last year's Google summer of Code, and make it more usable and useful. Specifically this means extending support to all HTTP methods, making it simpler to extend and override, and ideally supporting WSGI based applications, or at minimum CGI applications.
A relatively novice user should at the end of this project be able to say something like:
from Kamaelia.Systems.WebServer import WebServer
In order to start a basic webserver which serves static content.
A more advanced user should be able to specify where CGI applications exist:
from Kamaelia.Systems.WebServer import WebServerExtend & make more user friendly the Kamaelia Web Server
An even more advanced user may wish to support WSGI based application. No suggested syntax/API is given here since we would expect the student to explore programmer friendly scenarios here. It's worth bearing in mind that often web applications can care about HTTP method was used (POST, GET, PUT, DELETE, etc) when making the request, so looking at how to deal with this would be useful.
CGI support should be relatively simple given the existence of the UnixProcess component, though some adaptation to support standard CGI environment variables is likely to be needed.
A key benefit of this project is that this would enable Kamaelia to have a native, single threaded, scalable, extensible webserver written in a Kamaelia style. This not only simplifies maintenance but opens up interesting opportunities in desktop applications since Kamaelia works well in that environment too.
There are some potentially very interesting applications possible as a result of a client side, but scalable webserver that can integrate easily with lots of other applications. If you're curious, chat to us on IRC.
A Testing Framework for Kamaelia Systems
This project would aim to produce something similar to unittest/jtest, but in a context and manner which makes sense for individual Kamaelia components and also for Kamaelia systems.
Clearly this is a two part project, and two different main use cases:
This is a project that is something we have wanted for some time, but is now becoming clear that it would be extremely useful as Kamaelia usage continues to grow. Informal test systems must give way to automated. It is also expected that any student working on this will look at the existing way systems are developed and tested.
The key benefit of this approach is to push an extra layer of system verification into software systems - specifically allowing the testing and verification of concurrent systems. This is something hardware systems have had for a long time now, but a practical toolkit and with a practical verification suite for concurrent systems for software is extremely attractive. The primary test cases for a framework are expected to be existing Kamaelia systems, however where necessary small, but focussed examples are likely to be needed as well.
High Level Kamaelia 3D Modelling ComponentsThe purpose of this project is to produce higher level 3D primitives, which are still components such as walls, mannequins, water, clouds & terrain for creating and interacting with 3D worlds, ideally in a human friendly way.
By doing so it will be easier to contstruct a variety of 3D models. The core of this idea started from looking at an artist's mannequin - the kind often made from wood and poseable. Having a basic starting mannequin that's unskinned would be extremely useful, since it bootstraps alot of basic 3D work. Furthermore, unlike a wooden mannequin we can change things.
The practical outcome of this is that rather than using low level primitives of surfaces, a user could work at a much higher level.
The context of this project really revolves around the fact that last summer the Open GL components created were a success, and this is aimed at pushing usablility of these components up higher.
The key benefit of this proect is that it would become simpler to use Kamaelia for ad hoc 3D modelling. (Combined with the whiteboard's backplace, this could be extremely useful) These are all "for examples" - the mannequin & wall/floor parts however I view as pretty core.
Visual Editor for Creation & Composition of Shard ComponentsThis boils down to creating an editor for making components out of pieces of components - shards. These pieces are also by definition components, but unlike normal Kamaelia components are more functional, single shot than generator or thread based. Ie they don't really control flow.
The practical result of this is that it should mean that you would be able to largely create/prototype new components for Kamaelia graphically. A user would be able to use an editor to take pieces of components (Shard Components, maybe) and join them together using some connectors wrapping control flow.
A diagram showing a potential component structure can be found here. In this diagram you can see some parts of the diagram are reusable. Other parts can be reused as a chassis, and some parts simply can't be reused. The notation is based loosely on JSP, but the reason isn't to copy JSP (we're using it as a component system after all), but to use a metaphor that many developers are already familiar with. It is also relatively simple and completely abstracts out control flow - making components more likely to be reusable.
The project sits in the context that we already have a graphical composition tool (Compose) for standard Kamaelia component. However it is highly desirable to be able to create new low level components graphically.
Specific benefits of doing this project will be both the components created for editting essentially structured diagrams, but also the work done on developing the shards idea further. In the long term this offers opportunity to drive usability of the system up into the realms of the expert non-programmer user. Shards are a relatively new idea, so this project is partly about exploration of the problem space and partly about implementing the first pass at a useful tool.
Longer discussion on this topic has happened on the mailing list. (start of thread, continuation)
Kamaelia ExemplarThe aim of this project is for you to take something you've always wanted to do and create it using Kamaelia, with the aim of creating something which is a cool/useful demo/tool. (preferably useful tool :-)
The result of this should be something that you've wanted to build for sometime, that you think others will also gain from. From the perspective of the Kamaelia project, this should ideally be an exemplar of what can be achieved using kamaelia - be it...
The list of existing Kamaelia Components (excluding experiemental in /Sketches) can be found here:
If you *do* do this one, please follow the template given below in "Your Idea as a title"
Your Idea as a title
To be added over the next 24 hours. You can get ideas however by looking at last years page.
You can also add your own ideas here (hit the edit button).
This is an ongoing community based development site. As a result the contents of this page is the opinions of the contributors of the pages involved not the organisations involved. Specificially, this page may contain personal views which are not the views of the BBC. (the site is powered by a wiki engine)
(C) Copyright 2008 Kamaelia Contributors, including the British Broadcasting Corporation, All Rights Reserved