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@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. -- [EMAIL PROTECTED], 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. -- http://mail.python.org/mailman/listinfo/python-list
