I've posted a Chandler - Quicksilver integration hack over at the OSAF group blog.

We released Chandler 0.6 today.

After spending lots of effort trying to build up all the application areas at once, we decided to put all of our effort into building out one area, so that people would have something that they could use. The area we decided to build out was the calendar, since there's a real need for a good calendar solution. So this is our first step into calendar land. This version doesn't have every feature that you'd like to see, but it's a good start. The new project web site has some screenshots and some Flash movies that demonstrate some of the features. Features of note include: the ability for two people to share the same calendar (both people can create and update events) via a CalDAV server and support for managing events in different time zones. OSAF is providing an experiment CalDAV service for people who want to kick the tires. This service is using Cosmo, our Java based CalDAV server. Cosmo is licensed under the Apache License, and uses Apache Jackrabbit. There are still some sharp edges, but we are going to start using this version of Chandler as our day to day calendar at OSAF.

On the platform side of things, we've completely done away with our old XML based mechanism for describing Chandler parcels (extensions) and switched over to a system that uses Python to do the same thing. We've spent some decent effort on developer documentation, and we ought to be ready for brave souls to try to write some parcels. There are few sample parcels included in the distribution, including a simple (and I do mean simple) RSS feed reader, an interface to Amazon wishlists, and an interface to Flickr.

As always, bugs, patches, comments, and questions to the Chandler design or development mailing lists.

Yesterday we released version 0.5 of Chandler. The official announcement is here. Mitch's disclaimer about the suitability of 0.5 for end users is here.

0.5 was supposed to be done before PyCon, so that we could say "and everything that we're showing you can be done in the 0.5 drop". Obviously, we didn't make it in time for PyCon. If your are interested in finding out more about how to write a parcel, you can read our PyCon paper. We also have a tutorial that fills in some of the details that we didn't have time to cover for PyCon. Also, you can try out the parcels that were done at the PyCon sprints, which are in bear's subversion repository. There's some additional documentation that we know we need to do as a result of feedback from the sprints, so I'll post again when that information becomes available.

Elizabeth Grigg has questions about calendaring stuff:

One thing just from observing this Lightning / Mozilla spec page as well as the Chandler spec page: both projects are in an extraordinary low level of detail at the moment. There is virtually no high level thinking in the specs, which is perhaps fine for the task at hand. It doesn't help us outside observers, though. I would like to know, for both these projects, whether unseating Outlook is the cause celebre or is there something new for users in there somewhere.

As far as Chandler goes, we have a UI spec for the Calendar work we are doing for our 0.5 release (sometime in March). I'm not intimately involved with the calendaring stuff, so reading the spec is the best way to judge whether there will be something new for users there.

The other thing to know about our calendar work is that it will be based on CalDAV, a standard based on iCalendar and WebDAV. CalDAV looks like it is gaining momentum amongst calendar implementors, and if it gets sufficiently adopted, then the existence of interoperable clients and servers would definitely offer something to users: choice. The CalConnect consortium (of which OSAF and Mozilla are members) is working hard on improving interoperability amongst between calendars.

We're not subscribers to Netflix, but I like their notion of an "interest queue". In addition to the queue, there's what I'll call you interest working set, which is 3 DVDs. When you return an item from working set, you get the next item from the queue. I'd love to have a queue like this for books, and I'd also like to be able to specify whether queue requests get satisfied via my local library or via Amazon (or your favorite book retailer)

I love books, and I could quite possibly spend the entire rest of my life reading interesting books. When I was younger, I used to just buy books and have huge piles of them lying all over the place. Actually one of Julie's favorite statistics about me is that when we moved from the East Coast to the West Coast (courtesy of Taligent), the movers came and boxed up 57 boxes of books. A fair number of those are still in our garage, and as I've gotten older, I've taken to relying on libraries for as many books as possible. I've also taken advantage of Amazon's integration of used books, to purchase as many used books as possible.

In an ideal book lover's world, I could easily punch books into my book interest queue (I suppose my Amazon wishlist fills this role, except that it's not a queue), and the queue would first try to check the book out of the library for me. If that failed, it would try to get a used copy in good condition, and only after exhausting these two options would it order a brand new copy (it would have to ask first).

I suppose that this would be a great addition to a Getting Things Done workflow application...

Most of you who care probably already know that we did the release of Chandler 0.4 this week. You can read Mitch's blog for some additional details, Lisa's blog for some perspective on the release, and Oren's blog for a brief user report. This is still a bleeding edge release. I hope this is the last time that I'll have to write that, but we'll see what happens in the next 4 months. If you're brave, go get a copy, download it, and give us feedback. Even better, send us patches!

Morgen Sagen is working on the parcel system that allows os to build Chandler out of a bunch of small modules. Recently we've started using Twisted to handle networking functionality in Chandler. At our staff meeting last week, Morgen demonstrated a servlet system for Chandler which is based on Twisted's web resource functionality. He's got servlets for a telnet server, a simple photo blog, a Wiki that Grant Bowman is hacking on, and the beginnings of a pyblosxom servlet. When we (re)did the design for the pyblosoxm core engine, I tried to make sure that we could use another storage system besides the traditional file system used by *blosxoms. I think we're about to find out whether we did the design well enough.

If you're curious, Morgen has put up a subversion repository with all of his stuff.

Of course, no sooner do I do the protocol papers post, but Mark Baker and Bill deHora come up with their own lists.

Mark Nottingham has posted a list with his recommendations for papers on protocol design. This is very timely since we're having lots of discussions about the Chandler sharing protocol right now.

Well, I"m finally back in the saddle after a week at OSAF. It was five months since my last visit, which was probably a little too long. Some of the things that I talked about this week included several meetings on Item Clouds, a long clarifying discussion on our Data Model, and several discussions on Item Sharing. Anthony Baxter dropped by to tell us about shtoom, encourage us to think about voice in Chandler and suggest some ways to get more involved with the python community, so I suppose I'll forgive him for greeting me by telling me that I looked like ****. It was also a good time to be around to accelerate the coordination needed for planning the 0.4 release, and since we've hired a number of new folks, it was good to meet all of them, and spend some time developing existing relationships.

This trip I also managed to have an active evening social calendar. I spent one evening with our old family friends David and Katherine Fedor. It's been entirely too long since I saw them -- hopefully we'll be able to get the families together sometime soon. I spent another evening with fellow Brownies David Temkin and Sarah Allen who are both at Laszlo. David and I worked on Newton together, and it was interesting to hear his reflections on the project now that a number of years have passed.

I also ended up spending an evening with Marc Canter, his wife Lisa, and Phil Wolff. Marc is doing a bunch of open source style projects in addition to his consulting with various companies in the social software space. A lot of what he's doing right now centers around FOAF, and I'm looking forward to seeing the results soon. I think that there could be a nice tie in between the PeopleAggregator and Chandler's "sharing circles". One thing that Marc's interested in is being able to build another user interface on top of Chandler functionality. If we do a good job at MVC in CPIA, then this shouldn't be that much labor. Something that struck me as I talked with Marc was the long term view that he's taking of the stuff that he's working on. He's thinking multiple years worth of effort, a point of view that's been in short supply / disfavor since the dot com boom and "internet time".

Phil Wolff has gotten a fair amount of reading in our house -- he's hit both my and Julie's aggregator. In fact, when I told Julie I was meeting Phil too, she exclaimed "the thousand beers guy". You never know what will stick... Phil's been doing a lot of work with the Kerry campaign, and thinking about the issues related to taking the software artifacts created by campaigns and making sure that they have a life so that succeeding elections/campaigns could make use of them. He also asked me some interesting questions about Chandler. How will Chandler compete with a "Google in a box" appliance that includes search, e-mail, etc? How will Chandler do calendar support for events like Muslim prayers which occur a sunrise and sunset in your current location? This requires knowing where you are in the world so that you can compute when sunrise and sunset are. Food for thought, indeed. Phil had two thought provoking posts earlier that day, one on the 'Perfect' Corporate Weblogging 'Elevator Pitch' Competition (which he is judging) and another on social network software.

Lisa, Marc, and Phil got me the last night I was in town, and by then I was slightly draggy (I didn't say that Anthony was wrong), so I hope that I was suitably interesting company.

Marc Canter added his commentary to Liz Lawley's post in which she admits caving in and using an aggregator. I'm glad that Marc recognizes that a number of the properties of a digital lifestyle aggregator will be enabled by Chandler. We still have quite a ways to go before Chandler is ready to be the infrastructure to build something like what Liz envisioned in her post, but reading posts like these keeps me energized about what we're working on.

Since I started at OSAF I've been begging and whining for RSS feeds that would track the changes to our numerous Wiki webs. Today, I got my wish. I hope that this will help some of you as much as it will help me.

Here's an update on OSAF activities at PyCon

Jeffrey Harris will be attending in place of Andi Vajda.

We are going to have a Chandler BOF, Wednesday, March 24, at 9pm.

Today OSAF released Chandler 0.3. A lot of work has gone on under the hood between 0.2 and 0.3. We've made a number of improvements in the repository, and the Chandler Presentation and Interaction Architecture (CPIA) is making its debut in these release.

This is a developer oriented release. That means that there are a hardly any end user features / applications, and that the UI is (still) ugly. We want the next release (0.4) to include some real end user features and a real UI. Here are some things that we are interested in.

The repository has stabilized to the point of being useful for small applications. We're looking for feedback on the usability of the API's and data model. For people looking to do code related work, it's probably safe for you to start looking at the code. We can definitely use help in expanding our unit tests and performance/stress testing. Also, If you are interested in using the Chandler repository in your own application we'd be interested in talking with you about that.

CPIA is in its first release, and is taking its first baby steps. If you are a GUI framework person, we would like to get feedback on the architecture and APIs.

In short, this is a platform release, and it represents a real starting point on which Chandler end user functionality can be constructed. Some parts of the platform are in an early state, but if you would like to get in on things at an early stage, you'll be getting an accurate picture of the direction that we are heading in. You can get in contact with us via dev@osafoundation.org or via the chandler IRC channel irc://irc.osafoundation.org:6667/chandler

As a reminder, OSAF will be sponsoring a Chandler sprint at PyCon 2004. It is possible for you to attend the sprint without attending PyCon. We'll also have some tutorial material for people at the sprints, so previous experience with Chandler is not required. So if you are interested, please sign up on the sprint wiki page. In addition to the sprint, Mitch Kapor will be giving one of the PyCon keynotes, and we hope to have a Chandler BOF as well. PyCon is less than a month away, so register/sign up today.

Here's a few items from the Chandler repository that might be of interest. (There's lots happening in the CPIA and applications area as well, but I don't want to spoil their fun...)

• BerkeleyDB store for Lucene
It looks like we are going to use a native compiled (gcj) version of Lucene to do free text searching in Chandler. In order to do this, we needed to adapt Lucene to use a BerkeleyDB database as a store. Andi wrote this code and it's been contributed back to the Lucene project, which has taken the code into the Lucene sandbox. There's also the Python layer that exposes the Lucene functionality to Python. People have wondered why we didn't just use Lupy. The problem with Lupy is that it doesn't perform as well as Lucene, and it's basically a port.
• Busy Developer's Guide to the Chandler Repository
This document is supposed to help people get started using the repository. If you read it and it doesn't help you, let us know.
• Proposal for Chandler Query System
This proposal is the start of our query facility, which will probably be consuming my working life for the next few months. If your interested in this sort of thing, now is the time to drop in and make your opinions known. We got some really good feedback in today's IRC, so don't be shy. I'm not only looking for feedback, but I'm also interested in finding people who'd like to work on building this. So please stop by dev@osafoundation.org or irc://irc.osafoundation.org:6667/chandler and say hi.

Tomorrow's OSAF office hours IRC chat will be on the Chandler query mechanism. We have a basic proposal describing initial thoughts on a query language for Chandler. I'm interested in feedback and ideas, as well as people who are interested in helping in some way. If you are interested, the IRC is at 11AM PST. Here's the IRC information: irc://irc.osafoundation.org:6667/chandler.

It looks like OSAF is going to be running a developer's sprint at PyCon 2004 in DC. We want this to be a chance for people to start contributing to Chandler, so let us know if you want to come. PyCon is relatively low cost (as conferences go), so I hope that we'll get to hook up with some cool folks.

This means a trip to D.C. for me and (I hope) the chance to make some personal contacts in the Python and MacPython communities.

United Airline's Hemispheres Magazine has an article on Chandler.

Morgen tracked down the problem that was keeping all of Chandler from buliding on Panther. The problem was with wxWindows -- so it hasn't been keeping me from working - the repository unit tests don't need wxWindows to run. However, I did have to get a completely fresh checkout from CVS. This shouldn't work this way -- somewhere in hardhat we're not blowing away all of the stuff that's getting built. I already had this problem when I copied my Chandler tree from Debian to the the Powerbook. hardhat didn't blow away the SWIG binaries, and so it didn't build. When the build says clean, it should really clean up. That's a tall order when your build contains private copies of Python, wxWindows, Berkeley DB, DBXML, Xerces-C, Pathan, 4Suite, and more.

[Via CNET News] Intel has open sources a library for doing machine learning based on probabilistic network techniques. The licensing is BSD like, with a small survey to be filled out. This should be of interest to people working on next generatation microcontent clients.