There are some cool and simple applications for doing collaborative editing on Mac OS X: the programmer-focused Hydra (seeking a new name), and the rich text (and seemingly science/math) document focused iStorm. What the world needs now, is for OmniOutliner to bring this same functionality to outlines!
OmniOutliner is my favorite outliner. It has a lot of features, but keeps its focus on being an outliner, instead of being an outliner, a diagram editor (OmniGraffle can open OmniOutliner outlines and make diagrams out of them), and a presentation tool (apparently, Keynote and OmniOutliner can work well together though). OmniOutliner, thus, remains simple, fast, elegant, and surprisingly flexible. Now all I need to do is be able to share outlines with a coworker - either in read only mode ("here's what I'm doing"), or in collaborative editing mode ("here's what we need to do to get this project done"). I'd be happy enough with the first, and overjoyed at the second.
Dave Winer added a feature to Radio Userland a couple of years ago called instant outlining. It sortof combined instant messaging with Radio's outliner. You could subscribe to other outlines and read them in place, and get notified whenever a subscription changed. Since outliners are a great way to both document what you need to do and what you have done, this was a great concept. I'm not sure whatever became of it. I ultimately abandoned Radio. And I really did not like the user interface of its outliner - it was slow and cumbersome and not terribly OS X savvy, compared to OmniOutliner which I was already familiar with. And I must say, I've never been able to get along with Frontier for any major stretch of time - it just didn't work with my brain, even though it's heavily outliner based and I do love outliners. But it was (and still is) a good idea. It satisfies the read-only shared outliner requirement.
I know people who use the outline modes available for Emacs to maintain a personal log that spans many years. I have a similar OmniOutliner outline, DOING!, that I just put back on my Mac OS X dock. Some of it is organized by date (but that ends mid-december 2002), some is organized by project. Either way it's grouped, it's still nice to go back and look at what's been done - and also to see the thought processes applied to certain problems.
Now if only I could share...easily.
Zope is great at serving up dynamic content. But what about static content, such as images or large media files? Zope is great at managing such content (even without the higher level content management tools available), but it will never be as fast as a pure file HTTP server such as Apache.
Enter Zope's cache management system. This is a small framework within Zope to deal with caching and has a simple notification system for when cached objects change. Different cache managers can be plugged in. Two that ship with Zope are a memory cache manager, and an HTTP cache manager. The latter adds headers to the response for cached objects so that downstream cache managers (such as Squid) will cache according to a common policy. But other cache managers may be plugged in as long as they implement the Cache Manager interface (these are early examples of the component style development that dominates Zope 3). One we've been deploying to some success is FSCacheManager.
FSCacheManager does something interesting. It dumps cached objects out to disk where they may be served up by Apache or IIS, without requiring custom objects (such as FSImage, which stores images on disk instead of in Zope's object database) or changes to common Zope URL API's, such as absolute_url(). Using rewrite conditions in Apache, it can be set up so that an image gets fetched out of Zope only when there is no file system representation. When an image or other cached object is updated, the cache management invalidation machinery clears the marked file out of the file system, and it's put back there the next time an HTTP request is made for that object.
We've extended this concept to deal with an application we wrote that - for better or worse - stores its user managed images in MySQL. The images are retrieved through a Python Script that uses traversal_subpath that lets us have a url like data/SOME_UNIQUE_ID. Since these images are not being managed by Zope's machinery, we put in some explicit calls to a similar FS Cache type component that we wrote that also dumps files out to the file system to be served by Apache or other HTTP servers. Again - this speeds things up immensely. If an image seldom changes, why run an SQL query every time for every thumbnail on a page? Especially when you can make the URL uniform and independent of where it's ultimately served out of?
What this means is that most of the time, all that is being retrieved out of Zope is the dynamic page template. It's an effective way of moving a lot of the static data out to where it can be served faster without losing out on the many benefits of Zope.