ANN: Kamaelia 0.2.0 released!

phil hunt zen19725 at zen.co.uk
Wed Aug 3 14:48:00 EDT 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
>implies never)

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.

Unpack, please.

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

>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 mailing list