ANN: Kamaelia 0.2.0 released!

[phil hunt]

On Wed, 03 Aug 2005 16:57:34 +0100, Michael Sparks <michaels at rd.bbc.co.uk> wrote:
>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.

Isn't SMIL something that's goinhg to go into web browsers? In which 
case, you'd presumably not want to build one yourself, I imagine?

>> 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. 

What you say "bolting things together" do you mean writing Python 
code? Or will there be some other way?

What I have in mind is something like a project I worked on some 
time ago, where a program could be written by drawing boxes on a GUI 
application, and drawing lines (representing data flow) to connect 
the boxes. So one half of a VoIP application might look like:

  +----------+     +------------+     +-----------+
  | listen   |     | convert to |     | volume    |
  | on udp   |====>| audio      |====>| control + |
  | port 600 |     | stream     |     | output    |
  +----------+     +------------+     +-----------+

With something like this novel multimedia apps could be prototyped 
quickly (though making them into useful apps would take extra work 
-- in the case of a VoIP application you'd want a phonebook, for 
example).

>At the same time it's designed to encourage
>writing code in a way that makes it simpler. 

Examples would be useful here. Both of what it can do now, and what 
it will be able to do eventually.

>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)

So what it will eventually do is not cast in stone?

>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. 

What sort of objects? For example, if an application is audio 
straming, what sort of objects will be passed? Will there be onre 
object passed for each 10 ms or so of sound, or will there be a 
continuously-set-up object that passes the data throught it a byte 
at a time?

And if it's written in Python, will it run fast enough?

>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

My thought on this example:

      cdef class test(Axon.Component.component):
            def mainBody(self):
                  if self.dataReady("inbox"):
                        data = self.recv("inbox")
                        self.send(data, "outbox")
                  return 1

My first impressions are that it seems obvious to me what this does:  
it merely passes its input throught to its output (no doubt there
are places where such a null component is useful). Hopefully all 
code written with Kamaelia will be so clear.

Now I have some questions.

1. mainBody() is evidently being called at intervals. At what
frequency are these intervals? For example, if the data stram is
video data, will mainBody() get called once for each frame?

2. what data type is (data) in the code? Or can it be any type?


-- 
Email: zen19725 at zen dot co dot uk