hacking: January 2008 Archives
I ran across this blog post considering the idea that OSAF had a hard time making Chandler Desktop materialize because it's written in Python. I don't have any thoughts on that subject, but down at the bottom of the post I found this gem that addresses both Desktop and Server:
Chandler Server was built in Java because the first (and at the time, only) protocol it supported was CalDAV, which is an extension of WebDAV for calendar access. In early 2005, the Apache Slide project was the most viable existing WebDAV implementation that we could find. Slide was written in Java. The decision was made to hire a Java programmer to build the server on top of Slide, and thus I was hired.
Would it have been possible to write a WebDAV implementation in Python? Sure - Wilfredo Sanchez did just that a year or two later for Apple's calendar server. Why did OSAF choose not to do that? I'm not quite sure, but I think it was probably just the whim of the hiring manager, who I believe had more personal experience with Java and had come to OSAF from a startup doing WebDAV in Java.
In any event, there was no schism between me (the lone Java developer) and the Python guys (every other developer in the organization). There were just different starting points and the differing requirements between a single-user application and a server meant to support many more orders of magnitudes of users.
I'm sorry that we didn't produce the specific pieces of software he wishes for, but we had very specific goals, and neither "a flexible UI that can slice and dice data" nor "a reusable storage engine for unstructured data and communication" were priorities for our project.
I always wanted the core Cosmo calendaring engine and storage system to be shipped as a separate component which could be embedded directly into an application, but not having had that idea until a year or so into the project, it would have taken a massive effort (relative to the size of the team) to refactor the code and the build system to make it possible. I did some weekend projects to get a sense of the effort, and it was clear that we had too many other higher priority things to do instead. At the end of the day, we were trying to build a server for lightweight collaboration, not a toolset for other peoples' application development.
In regard to "I've downloaded the client and server, and it looks like a prototype that a competent developer could coble together in a couple of weeks" ... it's hard to formulate a polite response. All I can say is, the Cosmo web UI has one of the most mind-blowingly sophisticated implementations I've ever seen. I challenge anybody on the planet to replicate that body of code in a couple weeks, or even a couple months. And as for the rest of the server, well, either this guy hasn't actually looked at the code and has no real idea of what it does, or he's just got the hugest ego on the planet.
It's indeed strange that these two components use different storage engines. If I were to invoke Conway's law, it appears that the project had a schism between the Python and Java developers. I'm curious as to how the decision was arrived at to not develop the server side code in Python. Even if the project's requirements were in constant contention, the least the developers could have done was to build a solid and useful framework. I certainly would have loved to see a flexible UI that can slice and dice data or even a reusable storage engine for unstructured data and communication. I've downloaded the client and server, and it looks like a prototype that a competent developer could coble together in a couple of weeks. It's not something one would expect from a high visibility and heavily funded open source project.Desktop is a single-user desktop application. Server scales to thousands of users and beyond. Desktop's repository was built with features like versioning and access control that seemed like they'd be useful years ago, when the sharing model was envisioned to be P2P, but by the time OSAF came around to client-server sharing, those features were no longer necessary, and we didn't bother to add them to the server's storage system.
Chandler Server was built in Java because the first (and at the time, only) protocol it supported was CalDAV, which is an extension of WebDAV for calendar access. In early 2005, the Apache Slide project was the most viable existing WebDAV implementation that we could find. Slide was written in Java. The decision was made to hire a Java programmer to build the server on top of Slide, and thus I was hired.
Would it have been possible to write a WebDAV implementation in Python? Sure - Wilfredo Sanchez did just that a year or two later for Apple's calendar server. Why did OSAF choose not to do that? I'm not quite sure, but I think it was probably just the whim of the hiring manager, who I believe had more personal experience with Java and had come to OSAF from a startup doing WebDAV in Java.
In any event, there was no schism between me (the lone Java developer) and the Python guys (every other developer in the organization). There were just different starting points and the differing requirements between a single-user application and a server meant to support many more orders of magnitudes of users.
I'm sorry that we didn't produce the specific pieces of software he wishes for, but we had very specific goals, and neither "a flexible UI that can slice and dice data" nor "a reusable storage engine for unstructured data and communication" were priorities for our project.
I always wanted the core Cosmo calendaring engine and storage system to be shipped as a separate component which could be embedded directly into an application, but not having had that idea until a year or so into the project, it would have taken a massive effort (relative to the size of the team) to refactor the code and the build system to make it possible. I did some weekend projects to get a sense of the effort, and it was clear that we had too many other higher priority things to do instead. At the end of the day, we were trying to build a server for lightweight collaboration, not a toolset for other peoples' application development.
In regard to "I've downloaded the client and server, and it looks like a prototype that a competent developer could coble together in a couple of weeks" ... it's hard to formulate a polite response. All I can say is, the Cosmo web UI has one of the most mind-blowingly sophisticated implementations I've ever seen. I challenge anybody on the planet to replicate that body of code in a couple weeks, or even a couple months. And as for the rest of the server, well, either this guy hasn't actually looked at the code and has no real idea of what it does, or he's just got the hugest ego on the planet.
Another great hack from the young and fertile mind of Travis Vachon: chandler.el. Using the Atom API, you can save and edit notes in Cosmo. This could certainly be handy for folks who live in Emacs and like to drop stray notes into various buffers and text files. Travis, you should expand it to include a full-on collection browser and a microformat publisher.
OSAF is restructuring, and I'm moving on. They had to get rid of most of the staff, and I just wasn't feeling it anymore, so I raised my hand for the axe. Good luck to those who remain. Now that I'm no longer beholden to the person signing my paycheck to direct my work on Cosmo, I may be able to get around to some of the interesting things I'd been looking forward to, like CalDAV scheduling.
Dunno yet what's next on the job front. I've been checking out craigslist for the past few days, and I feel a scream build deep inside every time I see a posting about a social networking startup. I want to work on something that has real benefit to all society, not the fad of the week for geeks. Where's the intersection of renewable energy and web services?
Tangential rant: I guess I'd better go buy a computer science book so that I know how to reverse a linked list for job interviews. Not that implementing a basic data structure has ever had any bearing on any of the projects I've worked on in thirteen years, but for some reason this is the standard that computer science nerds set for potential hires. Don't get me wrong - I have no problem with whiteboard coding and think it's valuable to observe how a person breaks down a problem and works toward its solution, but how about asking me to demonstrate knowledge of an algorithm or design pattern that's relevant to the level of the stack where I'll be working? There's more to evaluating intelligence than determining if the interviewee sat through CS 200. For instance, asking for details about previous work and forcing me to defend choices I made. Metaweb has the right idea.
To be honest though, I'd really rather do something that doesn't involve sitting in front of a computer all day. Maybe I should join the Peace Corps. While I'm mulling that one over, if you want to talk to me about employment, here's my info.
Dunno yet what's next on the job front. I've been checking out craigslist for the past few days, and I feel a scream build deep inside every time I see a posting about a social networking startup. I want to work on something that has real benefit to all society, not the fad of the week for geeks. Where's the intersection of renewable energy and web services?
Tangential rant: I guess I'd better go buy a computer science book so that I know how to reverse a linked list for job interviews. Not that implementing a basic data structure has ever had any bearing on any of the projects I've worked on in thirteen years, but for some reason this is the standard that computer science nerds set for potential hires. Don't get me wrong - I have no problem with whiteboard coding and think it's valuable to observe how a person breaks down a problem and works toward its solution, but how about asking me to demonstrate knowledge of an algorithm or design pattern that's relevant to the level of the stack where I'll be working? There's more to evaluating intelligence than determining if the interviewee sat through CS 200. For instance, asking for details about previous work and forcing me to defend choices I made. Metaweb has the right idea.
To be honest though, I'd really rather do something that doesn't involve sitting in front of a computer all day. Maybe I should join the Peace Corps. While I'm mulling that one over, if you want to talk to me about employment, here's my info.
Fixed tons of bugs in this one.
http://blog.chandlerproject.org/2008/01/04/chandler-server-cosmo-011-released/
http://blog.chandlerproject.org/2008/01/04/chandler-server-cosmo-011-released/