On Wed, 03 Aug 2005 16:57:34 +0100, Michael Sparks <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
