Investors in a startup always want to know how the startup is going to get their money back — their exit strategy. “Get bought by Google/Yahoo/Microsoft” is a pretty common one in the Internet world. One I’ve never heard is “sell the company’s assets on Ebay”. Well, that’s exactly what Kiko are doing. Bidding starts at US$50’000. Very appropriate, I must say!
Things are rolling along on our XML-RPC library for PLT Scheme. At this point, the client is stable and well tested, and both the servlet and Apache CGI server implementations work and are poorly tested. However, one or two people were asking to make use of the server-side code, so we’ve made it available. Caveat developer.
Implementing an XML-RPC servlet is really quite straight-forward:
(require (planet "xmlrpc-servlet.ss" ("schematics" "xmlrpc.plt" 1 2))) (define (add x y) (+ x y)) (add-handler 'math.add add) (handle-xmlrpc-requests)
Dropping this code somewhere under the ‘/servlets’ directory should get you going. I’m still unhappy with the current state of the CGI code:
#!/path/to/mzscheme -gqr (require (lib "config.ss" "planet")) (PLANET-DIR "/tmp/PLaneTWeb/dir") (CACHE-DIR "/tmp/PLaneTWeb/cache") (LINKAGE-FILE "/tmp/PLaneTWeb/linkage") (LOG-FILE #f) (require (planet "xmlrpc-cgi.ss" ("schematics" "xmlrpc.plt" 1 2))) (add-handler 'add (lambda (a b) (+ a b))) (output-http-headers) (handle-xmlrpc-requests)
I imagine we’ll absorb the
output-http-headers into the
handle-xmlrpc-requests macro, and I really want to do something to improve the state of affairs w.r.t. PLaneT package handling in the CGI environment. As I said above: the server code in the library is in motion, and it will likely change.
As an aside, I expect stress-testing the server-side code will be interesting; Noel suggested using Ethereal to record interactions between clients (in other languages) and our server implementations, and then replay those interactions in SchemeUnit unit tests. A neat idea, and not something I had thought of.
Geektool takes shell commands and lets OSX geeks overlay their output on the desktop. (It does more than that, actually… it’s really quite awesome.)
I’ve been pushing on Snooze lately, our imminently-releasable persistence layer for PLT Scheme. I thought to myself: “How quickly could I knock up a GTD DB using Snooze?”
Turns out, not more than an hour or so to get something rolling. Now, I have a simple command-line GTD interface that uses Snooze for persistence, remind for rendering of content, and Geektool for rendering things to my desktop.
The lower-left portion of my desktop has a six week calendar overlaid, and above is an eight week calendar with a condensed list of the same information.
I’ll publish the GTD interface when I’ve had a chance to work with it for a while. For now, I suspect it will evolve as I decide how I like working with it best.