ANN: Kamaelia 0.2.0 released!
zen19725 at zen.co.uk
Wed Aug 3 20:48:00 CEST 2005
On Wed, 03 Aug 2005 16:57:34 +0100, Michael Sparks <michaels at rd.bbc.co.uk> wrote:
>> 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.
But it couldbe there eventually?
>>> * 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.
This is streaming audio, right? For non-streaming I can just use an
ftp or http server.
>>> * 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.
That's a slightly worrying answer for me, worrying because it seems
I've misunderstood the nature of the project. I assumed that
components for audio capture, and related activities, would be at
the heart of the project.
> 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......)
(or just sent the signal out multiple times)
>> (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
What -- good encryption? That's pretty much a well-known technique
these days (unless the NSA has some *very* advanced hardware in
their basement, which I strongly suspect they don't).
>>>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.
Again, this makes me think I've misunderstood the project.
>> 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.
When you say a mesh, what do you mean?
>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.
Oh. Could you give an example?
>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).
Visualisation, if done properly, ought to be useful to technical
>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.
That's kind of the impression that I've got.
>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.
That would be useful.
Or you could have subtitles in different languages, and the user
gets to choose which one to display...
Email: zen19725 at zen dot co dot uk
More information about the Python-list