ANN: Kamaelia 0.2.0 released!

[Michael Sparks]

I've reordered the q's slightly to avoid repetition... Also by answering
this question first, it may put the rest of the answer into context
better.

phil hunt wrote:

> At what stage of completion is it? 

This is something we deliberately try to reflect in the version number.
Yes, you can build network servers and new protocols relatively simply
at the moment. Yes, you can integrate with pygame in a limited useful
fashion at present. Yes we have audio playback.

However we don't have yet... (some examples)
   * Decent GUI integration yet. 
   * /Full/ pygame integration. 
   * Nice integration with pymedia
   * Direct support for Dirac.
Which aside from other things means you can't build (say) a video
& SMIL playback system trivially, yet.

As a result that's why the version number is 0.2 - whilst you /can/ do a
lot, there's a lot more to do. Clearly that also naturally implies that
we don't expect any end user to be looking at the site. (The low
version number will normally scare them away)

>>The project aims to make it simple to build networked multimedia
>>systems (eg audio, video, interactive systems),
> 
> There's plenty of software that facilitates networking, for example
> Python already has software for tcp and http clients/servers, and
> for xmlrpc remote procedure calls.

There is indeed.

> So what does Kamaelia do that's extra? I imagine it's to to with
> streaming large amounts of data. For example, a streaming video or
> audio player. Or VoIP, perhaps.

It's designed to make bolting things together to make these sorts of
system simpler and easier. At the same time it's designed to encourage
writing code in a way that makes it simpler. The natural side effect of
this is the  system might make it easier to take advantage of multiple
CPU systems as they come online, since it makes a system naturally
concurrent. As the original announcement said "Kamaelia is designed as
a testbed". And by testbed I mean testbed as it testing out new ideas,
see if they work and see if they pan out. (Not as in a testing suite)

Probably the best way of describing the difference is this... After my
talk about Kamaelia at Europython, I had an long chat with Tommi
Virtinan about integration between Kamaelia and Twisted. I haven't had
a chance to follow up with him yet regarding how this would work, though
I have set a line in the sand aiming to have easy integration between
Kamaelia and Twisted before Kamaelia hits version 1.0.0. The impression
I got from Tommi was that he was most interested in the communications
aspect - the fact we can bolt together systems in a manner directly
akin to Unix pipelines, though I suspect he found the graphines aspect
more interesting. 

Or as someone asking a similar question at Open Tech exclaimed after
I finally managed to explain it better to them "Ooooh - you're trying
to make concurrency EASY!".

> OK, so what do the components in the pipelines do?  What sort of data
> do they hold? Unix pipelines act on ascii files; I assume you are
> do this on audio and visual data. What langauage will the ele,ments
> in thne pipelines be written it? I assume some will be in C/C++ for
> speed.

Components are object instances of python classes. The data passed
between components are object instances. Clearly these python classes
can be written in python, C, C++, pyrex etc. Currently all of Kamaelia's
components are python based. Some existing components make calls
into some related C libraries via python bindings.. An example of
writing a component using Pyrex can be found here:
   * http://kamaelia.sourceforge.net/PyrexComponents.html

>>It is designed as a practical toolkit, such that you can build systems
>>such as:
> When you say "you" who do you mean? 

Generally I expect the readership of c.l.p/python-list at python.org to be
programmers. Python is generally easy to pick up and having asked
someone who's not done much programming beforehand (beyond
a small amount of VB and Access), and is pre-university to use the
system to build a simple streaming system prototyping visualising PVR
content on a mobile (and watching them succeed), they seem
relatively reasonable examples.

At some point, the ability to allow non-programmers to bolt together
Kamaelia systems would be desirable, but a first step is making it
simpler for programmers to bolt together systems. We currently have an
interactive visualisation tool(*), and the logical extension of that is
a tool that allows systems to be bolted together without knowing any
code.
   (*) http://kamaelia.sourceforge.net/AxonVisualiser.html

It'd be an interesting side project for someone to take forward, and
might be low hanging fruit in terms of projects. (Especially if viewed
initially as a tool for assisting development, rather than replacing
development)

> Is the audience programmers or
> less technical people? A project that allows non-technical people
> to build complex network applications is an ambitious one, but not
> impossible (I'd find it very impressive and very exciting,
> particularly if it runs on devices such as mobile phones).

It's a little ambitious at this stage, yes.

>>   * Ogg Vorbis streaming server/client systems (via vorbissimple)
>>   * Simple network aware games (via pygame)
>>   * Quickly build TCP based network servers and clients
> 
> What sort of servers and clients? 

Whatever you feel like. If you want a server to split and serve audio,
you could do that. if you want a server to spit out fortune cookies,
you can do that. (Useful only really as an alternative to a chargen
test protocol IMO)

>>   * Quickly build Multicast based network servers and clients
> Serving what? Could I use it, for example, to build an n-player
> encrypted  VoIP server to allow people to do conference calls over
> the Internet?

You could do that probably. (Though we don't have a component
for audio capture (though a read file adaptor reading from /dev/audio
might work depending on your platform I suppose) and audio
encoding at the moment, so those would probably be the core
components to integrate. If you want to use multicast over the wide
area internet you'd also have to convince all the people using the
system to use ISPs that support multicast......)

> (I mean proper encryption here, the sort GCHQ or the NSA can't break)

I'd be impressed if that could be written, using anything really. (Can't
implies never)

>>The basic underlying metaphor of a component us like an office worker
>>with inboxes and outboxes, with deliveries occuring between desks,

> That metaphor brings up an image (at least to me) that the sorts of
> data that can be communicated are things like documents,
> spreadsheets, business graphs, memos. 

They could indeed. The underlying framework doesn't differentiate
between data nor have any realtime aspect embedded in the system
at present. Just because we're focussing on systems that have a realtime
element and are multimedia based, this does not mean the system is
limited to that.

> May I suggest a different metaphor?  [hifi]

I'll think about it. It's closer to the model that pysonic seems
to take, and it implies a functional transform - ie /just/ dataflow
- rather than connected processing units that /might/ take time
to do processing. 

> OK, I get the straming part of it. But what asbout non-streaming
> stuff? What other protocols are necessary?

One example is peer to peer mesh setup. People normally
think of P2P as a distribution mechanism. However, the underlying
approach also very good at setting up communications meshes.
This could be of use in many areas, such as GRID based systems
for distributed rendering, application layer multicast, and network
multicast island joining.

Due to the illegal /uses/ of P2P, much work in this area is difficult to
reuse due to defensive coding. Decoupling development of protocols
from use of those protocols is generally a wide idea IMO.

>>Is that clearer ?
>>
>>A short summary of all that could be:
[ new descscription followed by useful comments, we'll take
  them on board, I think I've answered most points inline ]

> "innovative". This actually has two meanings. One is "is new /
> allows new things to be built".

Bingo. It could be argued the other is misuse as buzzword.

> That's certainly less lines of code than it would take in Tkinter.
> And easier to follow.

We're looking at tkinter as well. (Some tests at tkinter integration
are in CVS)

>>And you have a simple presentation tool !
> Now I'm confused. Is Kamaelia a GUI builder?

Multimedia systems have many aspects. They include taking in
audio/video and spitting out audio/video/pictures/text/... Take 
a look a SMIL if you're curious - it's a system that Kamaelia would be
incomplete if it made decoding/display/interpretation of SMIL
difficult.

We also have to be able to demonstrate system to other people
inside the BBC in a way non-technical people understand. That means
showing structures in a friendly dynamic way, showing pictures,
playing sounds (hence visualisation - looking inside running systems).

That means we need ways of integrating with systems like pygame &
other toolkits. If however I'm talking outside the BBC I'll try to give
examples which people might find interesting - such as building a
presentation tool. The blocks are very much like Lego & K'Nex and
adding in a new block enables all sorts of new applications.

For example, we could take the text ticker, combine that with a text
feed and have a personal autocue/teleprompter. Alternatively someone
could use it to have subtitles (say) at the opera displayed on a Nokia
770 (maemo) based device. 

> Ah, so now I'm guessing it allows me to write networked PyGame
> applications, where with just a few lines of code I can have
> networked streaming video on my pyGame screen... am I right?

As yet, no. When we hit version 1.0, yes. Why? Because we haven't
built components for video decode & display (and that's the only
reason). That's why I don't mention video normally - I prefer to focus
on where we are when announcing things, rather than where we're
going (leaving that to more appropriate forums).

>>Why wouldn't you use it? When Twisted is appropriate (Twisted is a
>>more mature framework).
> 
> The problem with Twisted, IME, is I don't understand the
documentation.

I can't help there, sorry. There *is* a twisted book coming out shortly,
which might be worth looking into (or getting from a library), if
you're interested...

Finally, please note: Kamaelia is part of an R&D project - not all of
the results will pan out. Some might, some might not. Unless you aim
for the Stars though you won't get to Mars. 

Best Regards,


Michael.
-- 
Michael.Sparks at rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.