One of the issues, IMO, regarding the conference we recently held was the lack of a decent collaboration tool. It became somewhat unmanagable to work together on this project. This may account for why certain people seemed to get piles of work, when there may have been others available who could have helped. It was simply too much work to give it out, oddly enough.

To actually spread the workload amongst multiple people, you'd have to explain what needs done, how you've done things so far, who is involved, when it needs done by, and so on. By the time you're done explaining that to multiple people, you could have done much of it already. This is most certainly inefficient :-)

There are tools out there that are designed to help with this. After the conference, I had been thinking about what would make a good tool to handle this. Actually, I need two things. I wanted a decent todolist/taskmanager for myself. I also had been considering writing a package that helped people organize conferences. After thinking each of these through, I realized I was being silly; those two issues are the same thing.

Whether it's my personal todo list, or conference organization, they both deal with projects, contacts, files, dates, etc. Often times, both even deal with needing to work with multiple people to accomplish the job.

I'm also pretty certain that what I want doesn't already exist. There are a number of tools, mostly web based, that attempt to handle this. My feeling on on most of these is that you spend more time administering the application than you do accomplishing tasks.

I need something simple. The term "simple" could probably be defined as an application that works the way I think. Now, dealing with things that think the way I do gets into scary territory :-) It also needs to be really "fluid".

So, the first thing to go is the web interface. Even with an app built on OpenThought, the web is no where near as fluid as is, say, curses. A well-designed curses application can be incredibly fast and easy to use.

At the same time, not everyone likes curses. Others who do like it may not always have convenient access to a shell. It makes sense to allow for different frontends, be it curses, gtk, web based, or whatever else people are interested in, which access a central backend process.

As soon as we begin getting into multiple users, we deal with access control. We have multiple users who will be accessing the same database, who may not have rights to see or modify everything on there.

People also think in terms of "their list", not databases. When I fire up my frontend application, I want to see all my todo items, not just those from one database. For example, when I'm home, I want to be able to see the stuff I want to be able to see both the stuff I want to get done around the house, as well as the things I need to do for the upcoming conference. Those are all things I would work on that evening. Of course, maybe I don't care about stuff from work at that time, so I can filter out certain items.

This all means that we'd need access control not only within one database, but that an application like this might need to be able to speak to multiple databases at various locations at any given time, each with it's own set of access control.

I've already begun work on this. My primary interface would be curses, so that's what I'm starting with. There's a bit of a learning curve there for me, so I've been messing around with how to make curses work.

There's some things I'm not sure about as well. The more interactive and real-time this is, the more useful it would be. So, what should the interface to the backend process look like? If we begin thinking web services, that's trivial t build, but it's stateless. Someone performing updates wouldn't be noticed until the next time our frontend client connected. I'm not sure that's what we want.

To handle communication between the client and server both locally or over the Net, one thing that jumps out at me now is dbus. A more heavy-weight option would be dce. Dbus is new, underdocumented, and has a changing api. I'm also not entirely certain I understand it's networking model, but that may be related to the documentation. DCE is designed for distributed computing, but may be more than I need. We'll see, I have some research to do.

Of course, this is all getting way ahead of where I am now. The initial design will probably just work with a local database and one user, we can work up from there :-) But the rest of this will be kept in mind during the implementation to make it as easy as possible to add this in soon.

It also lacks a name. I had initially thought of "borg" (Brain ORGanizer), but that name seems to be taken by a similar project already.

I'm open to thoughts and suggestions on any of the above. I'm also accepting patches as of right now too ;-)

Well, the problem I was running into was that I hadn't run into an existing interface that supported exactly what it was I wanted to do. And flexibility there is a big deal for this particular design goal :-)

It's interesting that you brought this up though. Actually, the key is that the front end has to be flexibile. Reuse of an existing backend application would actually be quite helpful, since this could end up getting complex pretty quickly.

I poked around a bit more just now, and wasn't having much luck finding an ical server that would do what we want.

However, expanding the scope of the search, I ran across a project I had since forgotten about -- OpenGroupWare. It's actually a groupware server that handles things like calendars, tasks, and the like, but it also appears to be flexible enough that we may be able to get it to work the way we want.

First, it uses Apache, and there is an open API for sending data to and from the server. That makes the interface simple.

That leaves the open question, how does it handle new data items. We need to add more complexity to TODO lists. They should be able to support trees of data, not just 2d lists. Each point in the tree also needs to support ACL's.

I'm sure we can add in the ACL support, even if it's through Apache, handling that before the request gets to the OpenGroupWare server. The outstanding question is whether OpenGroupWare's data model can be extended.

I'm currently installing this, it should be interesting. Thanks for the tips.