Always nice to wake up to a bad review of your work
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.
Leave a comment