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 ;-)