The original post in this thread brings up a key set of challenges for any GTD system that is to be truly trusted. Most of the resulting discussion seems to be about printing and syncing to PDAs, but I think thereís a broader issue to discuss here. In particular, samaparicioís last two bullet points ó access from multiple computers, whether your own or not ó are not fully satisfied just with printing.
I was, for a while, thinking about building my own GTD implementation. Right away, I got stuck on this issue of access. One thought I had is that this sort of problem has been solved already ó there are all sorts of applications that support an array of access mechanisms. I use Oracle Calendar at work, so Iíll use it as an example.
Oracle Calendar has a desktop client that runs on Mac OS, Windows, Solaris, and some Linux flavors. It is the most effective and efficient way to use the calendar; not that itís a great interface, just the best choice for desktop use. Anyway, all the data is stored on a server and cached locally. It is possible to use the client offline, in which case local changes are cached and synced with the server the next time the client connects. One can use the client application from different machines, and even multiple users can share a single client on a single machine.
When you are not able to use the client application, the server has a web interface to allow access. Not all features are available through the web interface, and being a web application, it is generally less efficient to use the web interface. But, the key point is that thereís always a way to get access to my calendar, even if Iím halfway around the world without my laptop.
Also, there is a Palm conduit for Oracle Calendar, available for the Mac and Windows at least.
Obviously, there are lots of systems that have similar access mechanisms in place. I think, though, that iCal shared over .Mac is a somewhat more restricted case ó AFAIK, you must use iCal to access your calendar, because thereís no truly platform neutral, portable mechanism for doing so.
So for me, I think any GTD system thatís going to be around for a long time ought to gravitate toward a similar model. Now Iím not suggesting that OmniGroup needs to do this for v1.0 or maybe even v2.0, but I think they ought to head in this direction eventually. Also, Iím not suggesting that OmniGroup get in the business of hosting everyoneís central GTD repository ó itís just not their core competency.
The interesting question to me is this: How could OmniGroup provide a server system that individuals, workgroups, or hosting organizations could set up with minimal effort. What sort of platform-neutral remote access would it provide? A web interface (maybe a bit like Tracks)? What OmniFocus features could be supported remotely? In any case, I think OmniFocus itself should always support a purely local mode of operation, unless explicitly configured to talk to a server. That way, itís not restricted to requiring a server at least some of the time (unlike, say, Oracle Calendar).
Last edited by tacartwright; 2007-02-05 at 07:23 AM..