It's not actually that exciting, just nice to get something working some place other than its original test environment. I'd like to tweak the code on the servers a bit and then I will publish the endpoint, adding, finally, a tiny bit of functionality to the so-called “w5” application. Maybe tonight, probably Friday.

Next up : the long, boring, slog of passing around and parsing Bloom filters in how many different languages?

Finally, support for filtering. Things will continue to be a little slow, yet, while I write test servers and reconsider some of the code that's had a month to grow mold.

Props to Anakim Border who heard my plea for help and sent a pointer to his Python library for doing Bloom Filters.

The (almost) all your keyboard events are belong to me release; sometimes known as the I was really hoping someone else would have implemented Bloom filters in Python by now release.

Almost because, for reasons I don't understand, the control key blocks all other keyboard events when invoked in a wxListCtrl context. If anyone out there knows for a fact that this is a bug in me, and not wxPython, please drop a line.

Just pushing this out the door since it works modulo filtering and some spit and polish for the UI. And servers that implement the API — one step at a time...

Trying to decide if, and how, to make this play with the so-called “w5” application” — not entirely sure what the benefit would be. Maybe as a guide and a grammer for extending the API to limit queries based location or keywords. I think this would place too high a burden on people running servers so I doubt it will happen.

Trying to decide if, and how, to make this play with the images that show up here every once in a while . At least passing date information and maybe a couple keywords.

Trying to decide how to automate that process and how Norman Walsh's jpegrdf tool plays with the RDF tools for managing photographs that I started writing — update : I solved this one enough for my liking by writing jpegrdfify

(Trying to decide how Java programmers would survive without shell scripts for generating those goofy CLASSPATH statements.)

Trying to decide who the first person to connect their photo management software to their address book will be and how they will account for the fact that out of roughly 38, 000 individual email messages I have collected just over 5, 000 unique email addresses. Actually, I sort of enjoy this one because it's the kind of statistic that makes usability experts get all weak in the knees.

Trying to decide if, and how, to deal with the fact that there doesn't seem to be any generic way to tell an RDF parser that x-urn:foo:bar:(.*) really means /home/asc/foo/bar/$1 .

Trying to decide what kind of punishment to metre out to the next person who tells me the solution to the problem is to add an entry in your DNS table .

Trying to imagine writing regular expressions as RDF statements which is a good as a time as any to stop.

Or: RDF/XML must die.

So, after a little bit of thought I decided to use RDF for the so-called “w5” application 's config file. I did this because there may eventually be support for multiple protocols. I like having a single description for each protocol and referencing it from within each service description. Then I can simply poll an rdflib instance for service subjects whose protocol predicate matches [insert protocol URI here]. And, you know, if there was only ever a single suitable application for XML it would be config files .

There's the rub; here's the salt.

After deciding to use RDF I spent a little more time and tried to develop a representation for the config file that would be terse and easy enough that a lowly human could read it. More importantly they could massage it by hand or a separate program. Every day I am annoyed that there doesn't seem to be any way to massage my web browser's bookmark file and then kick the program so that it will load the new data in to memory rather than overwriting my changes when it quits.

Maybe you want to pull down your best friend's list of random image servers and add them to your own. Via a cron job. Transparently, while the so-called “w5” application is running. Whatever, that's your business. It's not a hard problem and you should be able to do it.

So, that decided, I plodded away on other things and tried to ignore that which I knew was coming. This isn't the first time I've tried to create an RDF friendly XML application and I know that if the two play at all, they don't play fairly . But sweet Jesus I was not prepared for rdflib to read this and then serialize it as this .

What collective brain-freeze gripped the RDF weenies that they so blithely assumed generating multiple representations of the same data as disconnected as these was a good thing? Or that it should be allowed to happen at all? Please, don't say it. I know that an RDF thingy is a directed graph and that there are different ways of showing the data and that this is a Feature. And I know that it's only supposed to be handled by machines and persons of a Higher Order, which is bit like saying, circa 1992, that web pages will only be edited in WYSIWYG applications.

But to my naïve eyes the only design goal for XML that the RDF weenies paid any attention when they wrote the spec for RDF/XML was #10 : Terseness in XML markup is of minimal importance. All the other points on that list were seemingly overlooked by the desire to feed our new Robot Overlords.

The point is that RDF/XML essentially mandates that you have an RDF parser in order to manipulate any of that fancy meta-data you've collected. Anything else and there's just too much room for error in interpretation, whether it's done by an XML parser or a human being. I have nothing against machine processing, per se, but when it prevents actual people from doing the same by hand that's just a Bug.

Damn it Jim, I'm your friend — not a node!

Or a lump of coal.

<!-- my kingdom for the necessary fu to make
     rdflib read N3 files... -->

<rdf:RDF 
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns="x-urn:asc:w5#">

 <service rdf:about="http://www.foobar.com/xml/">
  <protocol rdf:resource = "http://xmlrpc.com/" />
  <login>hello word</login>
  <filter><![CDATA[ ... ]]></filter>
  <dc:title>Foo Bar Pictures</dc:title>
 </service>
 
 <service rdf:about="http://www.barfoo.net/xml/">
  <protocol rdf:resource = "http://xmlrpc.com/" />
 </service>
 
 <protocol rdf:about="http://xmlrpc.com/">
  <dc:title>XML-RPC</dc:title>
 </protocol>

</rdf:RDF>

And then...

#!/usr/local/bin/python

from rdflib.Namespace import Namespace
from random           import choice
from xmlrpclib        import Server
from rConfig          import rConfig

w5 = Namespace("x-urn:asc:w5#")
      
cfg = rConfig()
cfg.Load("/path/to/config.xml")

# insert idle speculation about the ability
# to overload an object's stringify method
# in python...
      
service = choice(cfg.ListServices(["http://www.xmlrpc.com/"]))
attrs   = cfg.DescribeService(service)
      
# this actually yields empty values but
# you get the idea — insert hand-waving
# about potentially non-existent keys here.
# maybe add some kind of helper method...
      
args = {"login"  : attrs[ w5["login"] ],
        "filter" : attrs[ w5["filter"] ]}

server   = Server(service)
response = server.w5.RandomImage(args)

Please remember that this is still a (slow) moving target.

With the release of the Mirror Project Random Image Widget just waiting for some final decisions to be hashed out, I started work on porting the code to a more generic random image client.

The first step was to add hooks that allow a user to specify a maximum width or height when displaying an image. I really don't want the number of options, or preferences, to exceed more than a handful but this one seems important. Using only myself as a judge I know that I would get annoyed pretty quickly if the little toy sitting in the corner of my monitor kept swelling to fill the entire screen.

As the screenshot illustrates this approach raises some issues with the menus available to user to which I say : the program was not meant to be used with your operating system's “magnify” tool — if you're going to set the maximum allowable width to 100 pixels, you'll just have to use the keyboard hooks if you want to pause the application.

Anyway, here's the road map for version 1.0 :

• add hooks to talk to more than one server
• add hooks to read server list (and any login data) from a config file
• add preferences widget to manage config file
• add hooks to watch config file for changes so that the program will just DWIM if a user changes the list of servers via the command line, or whatever
• figure out how to muck with the transport layer to allow the user to specify a maximum allowable download size — necessary?
• add hooks for handling some kind of Bloom filter-esque data store as a way of preventing the same image from being displayed twice
• finalize the API
• bless as 1.0

There will likely be source releases along the way.

Version 2.0 might have hooks for reading and displaying Creative Commons data, similar to what the mozCC Mozilla extension does. I'm not sure about this one because it feels like feeping creaturitus. But it would be nice to do something to help promote the initiative and another part of me thinks it's one of those applications where quick and easy access to that kind of licensing data is a no-brainer.

I've spent the last couple days creating a little wxPython application that periodically polls the Mirror Project for a random image and displays it in a window.

Whether this particular application, or the service it talks to, are made public remains to be decided.

Either way, I'd like to spin the idea into something more generalized that would allow me to display random images from Out There. So, I am thinking of adding hooks to store a list of servers that expose a w5.RandomImage() method and return a hash-like data structure containing six pairs:

• image (base64, as in the actual binary data for an image)
• who (string)
• what (string)
• where (string)
• when ( string )
• why (string)

Currently the widget only does this via XML-RPC but, depending on things like requirements for unencrypted authentication, it could be taught something like Atom.

The idea here is that people will build, or have built, the server-side widget that figures out how, and to whom, to return a random image. The method itself currently doesn't pass any arguments and if did it would be a single hash-like data structure like this:

• login (string)

  As in a traditional username:password string, or a key consisting of random gibberish or even a nonce if I ever get around to understanding them.

• exclude (base64)

  As in, something LOAF -ish in nature that the client passes the server indicating which images have already been seen . If the server has been taught to handle Bloom Filters it could use this data to check a return value before sending an image the user. This has the advantage of sparing the photographer wasted bandwidth and the viewer the annoyance of seeing the same image twice.

  Careful readers will note that this means the server needs to return a seventh pair (a unique ID for the image) not listed above — cookies and a glass of milk for you!

None of these parameters are required. They are included as a way to provide some baseline of control and convenience for people on both ends of the connection but, really, nothing more.

After all, this is just a dumb client for displaying chance images that live out there on the Network because it's the kind of thing that makes the day a little richer. If you feel like you're going to need to be able to blog something as it travels across your desktop, take a screenshot or something.

Anyway, the next step is to figure out how to make the widget in hand into a stand-alone binary on the various platforms. Then I will work on adding the required fu for talking to muliple servers.