I'll be around at the LONIX User's meeting this evening which is described on their next meeting page. Any other Python people interested in meeting up are welcome to say hi! :-)

Just a note to say that I'm giving two of the "business briefings" at Linux World, Olympia over the next two days, first in the morning of the 25th with a repeat on the 26th. I'm also likely to head towards the London Linux users group meeting there in the evening of the 25th and if any other pythonistas are likely to be around, it'd be good to meet up. I'm planning on putting the contents of my presentation up on this blog after giving the talk. I'm, unsuprisingly, talking about open source at the BBC, use, collaboration, origination, and talking about this in terms intended to be relevant to companies seeking to learn from my experience both at the BBC and in the private sector before joining the BBC. As I say, I'll be putting the content of the talk up after Linux World is over (probably on friday).

Blatant promotion - I wrote an article for Linux Format on Kamaelia, specifically focussing on the whiteboarding app, but also covering some of the background on how components worth etc, which has just been published today in this month's Linux Format. I think the article/tutorial comes out pretty well myself :-) There's also an interview with yours truly in there with possibly the 2nd scariest photo of me I've ever seen.

I wrote this as an example of a relatively simple, but non-trivial network protocol. It creates a server that sits there waiting for connections. Anything that you type at it updates the markov chain for anyone/everyone connected. The protocol handler itself could be bolted into an IRC bot instead so you could have a deranged bot sitting on a channel which talks vaguely on-topic (but relatively - not totally - incoherently) most of the time. I thought I'd blog about it because it makes quite a nice fun/simple introduction to Kamaelia in it's own special way. The markov chain used is based on the one here. (courtesy of a google search)

import Axon, random
nlnl = '\n', '\n'
key = nlnl

def new_key(key, word):
   if word == '\n': return nlnl
   else: return (key[1], word)

class Chatty(Axon.Component.component):
   data = {}
   def updateChain(self, message):
       key = nlnl
       for word in message.split():
           self.__class__.data.setdefault(key, []).append(word)
           key = new_key(key, word)

   def response(self):
       key, result, word = nlnl, [], None
       while word != "\n":
           word = random.choice(self.__class__.data.get(key, nlnl))
           key = new_key(key, word)
           result.append(word)
       return " ".join(result)

   def main(self):
       while 1:
           if self.dataReady("inbox"):
               message = self.recv("inbox")
               self.updateChain(message)
               self.send(self.response(), "outbox")
           yield 1

if __name__ == "__main__":

    from Kamaelia.Chassis.ConnectedServer import SimpleServer
    SimpleServer(protocol=Chatty, port=1500).run()

And that's pretty much all there is to it. As you'd imagine (I hope), a Chatty component is created to handle any accepted connection on port 1500, and anything the user types is received on the inbox "inbox", used to update the class's markov chain DB, and then generates a response to send to the outbox "outbox" (meaning it gets sent to the socket). The upshot is the more people who connect, the more the database gets updated.

The nice thing about this is that the bulk of the code here focusses on the logic that's desired, not on any networking details. OK, this example isn't ideal because it misses some important things like shutdown and what happens if the connection disappears, but it also is interesting because you can test the component in isolation as well:

Pipeline(
    ConsoleReader(),
    Chatty(),
    ConsoleEchoer(),
).run()

Which is a nice thing to be able to do! If you wanted to train the markov chain server you could also do that as follows:

Pipeline(
    ReadFileAdaptor("SomeTrainingMaterial"),
    TCPClient("127.0.0.1", 1500), # assuming localhost
    ConsoleEchoer(), # May as well see the deranged output :)
).run()

The fun thing about this trainer is that you can see the output from the markov chain during testing as well :-)

People clamouring for DRM systems continue to miss some key points. Two links to two articles which are interesting counterpoints to each other. One claims technology will win the day pointing at legal services as successes. It misses the reason the legal systems are a success are because of service not technology. The other points out the reason why teens (especially) engage in infringment is because they have no other real option - no one is providing them a useful service. The former group should look at the latter and think about how to deal with this.

The BBC reports on an anti-piracy campaign which assumes that technology can win the day - that technology designed at its core for copying and transforming bits from one place and form to another can be used to lock down such things. It cites the success of legal music downloads as proof of this. The irony is in reality the reason people use iTunes has nothing to do with DRM, but everything to do with service. The DRM enables content providers to think "this will protect my work", when the existance of Hymn and a dozen other tools prove this to be a fallacy. And yet they have an income. Why? Because iTunes provides a service that people want at a price people want.

However, it is also an exclusionary service, what about those using unsupported operating systems? (This impacts me for example, I'd be tempted by the TV, but I'm happy to wait for it to turn up on Sky) What about those who don't have a credit card? For a business the market size is certainly large enough, but a public service which needs to be universal access, it can't be the right model (can it?). This leads me to the counterpoint article by Julien McArdle .

In this article it points out that if you're (say) between the ages of 12 and 18, you can't get a credit card (OK, in some countries you can, but not here). You can't buy access to iTunes in a shop (again, in places in the US you can, but not here). You have two options - either go to your parents and ask them to buy your music or find some other way to get it. Now we're talking about teenagers, the demographic that is stereotyped as not getting on with their parents at all, especially on the point of music. Yes, in an ideal world this wouldn't be a problem, but we don't live in an ideal world.

As a result they have limited options for listening to music on an iPod or similar.

One obvious option is to go and buy the music at a shop and rip it yourself. This sounds fine since everyones getting paid, but is actually copyright infringement in the UK (though you'd be hard pressed to show lost revenue). However, bear in mind at this point, if they take this route they have already infringed copyright. It doesn't matter that they've paid for it, it doesn't matter they didn't download it off Kazaa or Limewire, or similar, they've infringed. They're damned if they pay and rip, and they're damned in the same way if they download without paying.

Now consider someone who doesn't have any idea about how to rip a CD that they buy, transcode it to AAC, MP3, or WMV. What option do they have? Well, they can ask someone who does know how to do this for a copy of their music. And given sharing is blugeoned into children (in the nicest possible way) from birth, the default is for people to say "sure". As a result, those who can rip share with their friends. Those who can't share what they get with their friends. (right or wrong, this is what happens and the basic core motivation boils down to conditioning like "Share your toys/book/chocolates/cds with your brother/sister/friends")

And that's how a P2P system gets populated with unauthorised copies - people being nice to their friends... multiplied by the Kevin Bacon game. The next step in this chain is this - why would someone who can't rip a CD buy that CD if all it's going to be is a £15 ($30) table coaster? They're teenagers, not rich. If they could spend £15 ($30) on music and play it on a device they want to play it on, they would.

The sad thing here is everyone in that chain would agree - the artist needs to be paid for their work. The doubly sad thing here is, the bulk of people in this demographic who would want to pay for music (so their favourite artists can make more music), and are targeted as pirates have no other realistic option.

Where's the service that makes iTunes (or almost any other online service) realistic for that demographic clamouring for music? DRM won't stop them infringing - providing the service they can actually use and will happily pay for will. There's a market there, and if you can make them happy you'll be rich.

Finally, note: I'm not saying here that DRM is per se a good or bad thing, I'm deliberately steering away from saying DRM is good or bad. One good thing about it is that it encourages trust in a system for many content producers, owners and providers. The worst thing (IMO) about it is that it is currently divisive.

The basic technology has merits beyond the music world for it's ability to mark content as private (family photos, videos) and keep it private (as some people wish some things they'd said would be).

For the record, I very very very rarely buy music (I watch more TV or listen to the radio), but when I do I go in a shop and buy something classical in a sale - I like physical shops - you can often get a nice coffee nearby :) .

Some people wonder why I don't talk about my private life online, or 'silly things' like whereabouts I live in the world. The response  I generally give is "it's private". Some people however seem to think that in the modern age privacy is a bad idea, that if you want it you must have something to hide - as if privacy isn't a basic human right (Toilets have locks for a reason). Bruce Schneier's written an excellent article about privacy which sums up the debate as liberty vs control. I personally think that it really boils down to privacy matters and if its none of your business, it's none of your business no matter who you think you are, however aside from that final summing up I think its a great article.

It's also one of the reasons I'm interested in mechanisms to allow private communication to be integrated into Kamaelia, since the people engaged in private communications need to trust their not being evesdropped. This turns out to be a harder problem with Kamaelia than you might expect, mainly because of the high degree of decoupling in Kamaelia. (This is probably a good thing overall, since if you do manage to implement something you can trust you'll probably have a higher degree of trust in the system as a result. There's other practical applications at work (such as field journalists in hostile zones, or places with extreme censorship), but for me the basic need is one of privacy.

There are many RSS sources on the web, and people are beginning to look at them as a form on unix pipe for the web. Whilst this isn't a bad analogy, it misses a number of things about pipes (especially graphline type pipe systems), which would make things more powerful. We've got a specific need here, so I'm thinking "what's the most Kamaelian way of doing this", and starting from the perspective of "what's missing". The rest of this post discusses the editted highlights of my thoughts.

What's wrong today with a web RSS feed as the universal pipe connector?

• It's pull only
• There's no apparent _standard_ way to push back - trackback is the closest I can find right now, but that's application specific, not a generic connector.
  
• There's no mechanism for actually creating the pipe aspect as yet today
• As well as pushing into the object you would then want to pull out the other sides (taking the Kamaelia viewpoint that you don't have just stdin/stdout)
• The web is not the only source. Any device could easily publish one or many RSS feeds via zeroconf technologies, meaning you could fire up your machine, find out who's publishing a resource locally, and then play with the resulting feeds.
  

Ironically on the Kamaelia project we've now got a specific need where this would be of use, so I'm extremely tempted to deal with this. As usual the specific need is trivial - posting subversion checkins as news onto the website, but it would be extremely useful. The resulting tools would be reusable, which could be quite fun in a number of different places :)

An email address I had many moons back I now have again :-) You can now reach me once more at zathrus >A.T< mad >D.O.T< scientist >D.O.T< com :) (Note that's zathrus with a "u" not spelt correctly)
Sorry about the obfuscation, replace >A.T< with @ and >D.O.T< with a . (mutter nasty things about spammers)

Looks like I haven't been paying attention to the prolog world. Since I last looked they've also gone all OO. Just heard about logtalk, which strikes me as interesting and perhaps coming back to. Description from freshmeat: Logtalk is an open source object-oriented extension to the Prolog programming language. Integrating logic programming with object-oriented and event-driven programming, it is compatible with most Prolog compilers. It supports both prototypes and classes. In addition, it supports component-based programming through category-based composition.

So not quite the prolog I originally learnt then ... :-) Or perhaps as prolog would say: no. Mind you, I've always thought that if prolog could be made useable by the average person that it would have some really interesting applications for users. After all, being declarative it does allow you to do a lot more by doing a lot less. You've got to wonder what the implications of a tutorial on event based systems in prolog where messages to objects are events have for other systems.

Well, the release candidates for Kamaelia 0.5.0, Axon 1.5.1 have been created merged with the megabundle and uploaded to sourceforge, next comes the steps of finding what's broken (esp by last minute additions), and fixing. Meanwhile I've also written the Kamaelia article for Linux Format (december issue probably!), which is really cool. It focusses on the whiteboard largely, what you can do with it, and also has a section on how Kamaelia works from basic principles through to building graphlines.

I'm really quite pleased with it, and look forward to seeing what Linux Format do with it. (It's bound to be editted down and I imagine have its tone changed at least slightly!) It's made me realise that we missed out some dependencies from the MegaBundle, and that some areas need fixing, which is really useful.