Chandler finally reaches a 1.0 release [LWN.net]

By Jake Edge
August 13, 2008

The Chandler project has been around since 2001, periodically releasing new versions of its personal information management (PIM) tool, but never quite reaching the 1.0 milestone—until now. Over that time, Chandler has undergone various major revisions of both code and philosophy, while the rest of software industry has hardly been standing still. Whether Chandler is relevant or important going forward is an open question, but it does have some interesting ideas as well as potentially useful code.

Chandler is the brainchild of Mitch Kapor, of Lotus 1-2-3 fame, who started the project as part of his Open Source Applications Foundation (OSAF). Kapor and others have funded OSAF to work on Chandler over the last seven years, but in January all that changed. Kapor announced that he was leaving the board and only continuing to finance Chandler until the end of 2008. The 1.0 release is to some extent a "last gasp" attempt to build a community of users and developers to continue Chandler development down the road.

Since the time when Chandler was originally envisioned as a shareable calendar and information manager, many other, similar tools have come about. Evolution is a free software example, while Google Calendar is popular, but proprietary and closed. Neither of those cover the full feature spectrum that Chandler aspires to, but they have been available for quite some time.

The idea behind Chandler will be familiar to those who know about the Getting Things Done system. Organizing and integrating to-do lists, calendar events, email, and notes into a single system—and single application—is the driving force. These items (known as "notes") can be tagged into various collections (like Home, Work, etc.), assigned as events in the calendar, or mailed to others.

The calendar works like one would expect. Events have the standard fields: start/end time, frequency for recurring events, various alarm options, etc. Events get color-coded based on their collection and the calendar itself can be viewed at various granularities: day, week, or month. Based on their proximity in time, as well as user choice, events get "triaged" into categories of "Done", "Now", or "Later".

There are multiple synchronization options available with Chandler. Keeping calendars in sync amongst multiple different systems, with different import/export formats is clearly something that the Chandler team focused on. Because Chandler is cross-platform—written in Python and available on Linux, OS X, and Windows—it can interface both with tools that run on those platforms as well as with internet services like Google Calendar. As yet there is no Outlook/Exchange synchronization available which leaves out a rather large portion of the potential audience one would guess.

The Chandler desktop is only one of two pieces of the Chandler project; the other is the Chandler server. It is the means to share Chandler information, either with other users or just with other computers. Data can be synchronized to the server, then retrieved on another Chandler desktop elsewhere. For those that do not want to run their own server, the project runs a version of the server as the Chandler hub, which offers free accounts.

The 1.0 release looks like a solid tool. It has some enthusiastic users, but will that translate to a larger development community? Chandler development has always been directed—and funded—by the OSAF, so it suffers from a smaller development community than it might have otherwise.

Projects that start as proprietary, but then open their code, sometimes have difficulties allowing a community to influence or control the direction of that code thereafter. We have seen that with OpenSolaris and other projects. Chandler seems to suffer from some of those same problems, even though it came about differently. By removing the funding, Kapor may well have jump started Chandler development.

Seven years is a long time by any standard, but for software, it is an eternity. By keeping a relatively tight grip on the direction of the project, the OSAF may well have kept interested folks who were not on their payroll from getting involved. If the project can move to a more open style, with frequent releases, it may be able to regain some of that lost time. It is an intriguing tool, but it is way behind schedule.

(Log in to post comments)

Chandler finally reaches a 1.0 release

Posted Aug 14, 2008 11:11 UTC (Thu) by sitaram (subscriber, #5959) [Link]

I'm not a pythonista by any means -- been a perl guy for too long and the whitespace thing
(subconsciously) reminds of things like RPG...

But I am genuinely curious to know why you would make such a generic statement.

[Apologies for side-tracking the discussion from Chandler of course...]

Offtopic: Python

Posted Aug 14, 2008 13:39 UTC (Thu) by ikm (subscriber, #493) [Link]

The statement is that generic because it was about the language itself. There are two things
I'd like to point out here.

First one is that dynamic languages tend to postpone errors as late as possible, contrary to
the static, compiled ones. Knowing how many of errors are caught at the compilation phase when
one does C++, I feel thrilled, or better yet, outright sick having no such thing in Python,
and hence having all the errors caught as one try using what you've made. Suppose one has some
rare code path which leads to a foo.bar() statement in one's program, and there's actually no
bar() method in foo. If it was in C++, bah, you get compilation error immediately. But in
Python the program would happily work ever after, until some day the thing would finally go
there and explode. I absolutely hate this. While the property of being dynamic has some
merits, I'd rather say this hurts more than it helps.

Second one is that Python, like any other scripted language alike, is just slower and consume
more memory than the usual C/C++. I don't like that. Nowadays there's a popular opinion that
computers are fast and RAM is cheap -- well, not only computers are fast and have RAM -- they
also differ from each other and they can do multitasking as well. Thing is, no one can know
where to draw the line, except when you do some dedicated server or embedded development. The
whole idea of the scripted paradigm, as I understood it, was to have more code in less time. I
don't like how it turns out in reality, though, because what we have as a result seems to me
to be more like "more code done by less competent people". This is most visible at the job
market, where nowadays are just too many mediocre scripted programmers (the ones who do web
and corporate environments mostly, but spreading to other tasks as well). They slowly fill
available space, pushing out true old-school grey-bearded pros to sides and niches. Maybe it's
just what life is -- mediocrity. But I'd rather have a program done by a pro, a program which
is fast and bug-free and consumes less resources at the same time than some crap that crawls
and dies all the time, but, hey, was done by some cheap if incompetent developers (no
intention to attack anyone, I'm criticizing companies' hiring tactics here). With FOSS, I'm
not saying that I hate people who do mainstream desktop programs in scripted languages, I
usually just say "No, but thanks". And also feel a bit sorry that these people didn't decide
to stay with the usual C/C++.

I think scripted languages are good to write maintenance stuff and such, just like what
/bin/sh is used for. While Python is more powerful than that, I'd still rather not see it
being used to create programs for mainstream desktop use, although I think it's ok to use it
in dedicated environments with known resources, like web development (whether this is
beneficial or wasteful is up to the producer to decide, I as the consumer wouldn't care much).

Offtopic: Python

Posted Aug 14, 2008 15:18 UTC (Thu) by marduk (subscriber, #3831) [Link]

It's called pylint.

Offtopic: Python

Posted Aug 14, 2008 16:18 UTC (Thu) by hathawsh (guest, #11289) [Link]

I disagree with you, as would many others, but this is not right forum for that discussion.

Offtopic: Python

Posted Aug 14, 2008 16:23 UTC (Thu) by zooko (subscriber, #2589) [Link]

You made some reasonable points. I happen to disagree, but I admit that your points *could*
be right.

However, I'm interested in testing your hypothesis empirically. If you're right, then
Chandler would tend to have more runtime errors and take up more memory and CPU than a
comparable program written in C or C++.

Is there another such program that we could compare Chandler to? This is a serious question.
Hopefully our Grumpy Editor will check some out, and maybe when he does he'll pay attention to
the incidence of runtime errors and to memory and CPU usage.

By the way, I'm biased because I'm one of the authors of an app written in Python --
http://allmydata.org Tahoe, the Least-Authority Filesystem. We have shared some code and some
ideas with the Chandler project over the years.

If you find that Tahoe incurs runtime errors I would love to hear about it -- there are
currently no known errors of that type in Tahoe. This is probably due to our extensive test
suite which covers 93% of lines (http://allmydata.org/tahoe-figleaf/current/) and which gets
executed on eleven platforms on every code commit (http://allmydata.org/buildbot/waterfall).

Also if the memory or CPU usage of Tahoe is too great then I would be interested in that, too.
(We do use C or C++ for the CPU-intensive parts: cryptography, erasure coding, etc..) We have
automated measurements of the memory usage of Tahoe
(http://allmydata.org/tahoe-figleaf-graph/hanford.allmydat...) and I
would say it is currently "bad, but not critical", and probably no worse than a similar C++
app.

Offtopic: Python

Posted Aug 15, 2008 3:14 UTC (Fri) by dmag (subscriber, #17775) [Link]

"If it was in C++, bah, you get compilation error immediately. But in Python the program would happily work ever after, until some day the thing would finally go there and explode."

I must assume that you ship your programs as soon as they compile. Because if you run your program (even just once) to see if your new code really works, then you can't complain because that's what the scripters have to do too.

"The whole idea of the scripted paradigm, as I understood it, was to have more code in less time. I don't like how it turns out in reality, though, because what we have as a result seems to me to be more like "more code done by less competent people"."

Non-sequitur. Sorry, you failed to make a logical argument.

"But I'd rather have a program done by a pro, a program which is fast and bug-free and consumes less resources at the same time"

Me too, but what does that have to do with programming language? Speed (and resources) are usually proportional to the algorithm you use. Bug-free is proportional to the amount of testing you do and/or the smarts of the designer.

Back on topic:

I actually downloaded Chandler and tried it. The application is not snappy, and makes me think I'm using a web application because screen updates take time. Also, their UI needs to be re-thought: It assumes you always want to copy items instead of move them to new categories. If you create an item and immediately delete it, you'll later find another copy in the "desktop" view.

I could see how some people would live with it and it's warts. But I'll skip it for now.

Offtopic: Python

Posted Aug 15, 2008 10:17 UTC (Fri) by rwmj (subscriber, #5474) [Link]

The poster was referring to code paths which aren't exercised in normal use. 'foo.bar()' is on some rarely used error path, and it's not possible to completely test all paths through your code. That's why the compiler ought to be picking up these errors for you, rather than relying on very extensive yet incomplete test suites. Not that having a test suite is a bad thing, but no one can object to the compiler finding even more bugs, as early as possible in development.

Speed (and resources) are usually proportional to the algorithm you use.

Yes, but Python also suffers from a 10-fold disadvantage in speed and resource usage, even when the algorithms are identical.

Rich.

Offtopic: Python

Posted Aug 15, 2008 14:33 UTC (Fri) by k8to (subscriber, #15413) [Link]

Speed, certainly, resources hardly.

Offtopic: Python

Posted Aug 15, 2008 17:03 UTC (Fri) by mosfet (guest, #45339) [Link]

There are solutions on the horizon to get Python execution speed comparable to C or C++. Have
a look at the PyPy and LLVM projects.

Offtopic: Python

Posted Aug 15, 2008 17:05 UTC (Fri) by drag (subscriber, #31333) [Link]

> Yes, but Python also suffers from a 10-fold disadvantage in speed and resource usage, even
when the algorithms are identical.

Quite frankly that irrelevant. It really is. It doesn't seem like it at first, but it is.

Why?

Because the vast majority of a program isn't speed sensitive in any sense of the world. Only a
small amount of most programs consume the vast majority of resources the program uses. And
because of the nature of programming it's often very difficult to determine which parts of the
programs are going to be the troublesome part.

(Now, of course, the following does not trump good programming design or performance oriented
thinking.. in fact it augments it.)

So when you program in python and you reach a point in your program which performance becomes
a serious issue, so that figuring out better algorithms in python isn't going to get you
better performance, then you have to hunker down and rewrite the troublesome parts in C and
import it back into your program as modules.

And, since, there is a number of different ways to do this that makes it easier then it used
to be.. Such as programming in python-C hybrid languages like Cython or Python.. AND you've
already done the hard work of designing better algorithms in a higher level language then
you'll likely end up with better performing code then if you started off programming in C in
the first place.

That is the key to having very complex python applications that perform very complex things is
to not program everything in python.

Python isn't like Java were everything needs to be java-this or java-that. It's quite happy
integrating with other languages. So you use what is appropriate.

--------------------------------------

A case in point:

Git is a example of a program that uses lots of high level languages and is very good
performing. It does not use any python, but it does use a large amount of Perl and bash shell
code.

Given that Perl is slow, and shell scripting is not only extremely slow.. it is very very
limited in what it can do, then that means that Git should be very slow and limited, right?

Well no. Of course not.

Git not only is faster, it's magnitudes faster most any other RCS (for the features that the
designers care about). Many that have been written in C++ and don't use any shell or perl. And
they've done that in less time and effort then what other RCS have benefited from.

--------------------------------------

Given infinite amount of time, skill, and resources C++ will always be a better choice then
Python. No question about it.

And given infinite amount of time, skill, and resources C will always be better then C++, and
in turn Assembly will always be better then C.

(since C was originally written in assembly, and C++ was written in C, then nothing that is
done in C++ can't be done in C, and nothing that can be done in C can't be done in assembly.
And, of course, the reverse is not true.. Assembly can do things that can't be done in C, and
C can do things that can't be done in C++.)

None of us have infinite resources and infinite skill.

----------------------------------------

The theory is that using high-level language isn't going to just allow you to crank out more
code quicker. The theory is that it allows you to crank out _better_quality_ code more
quickly. (But I can't tell you for certain that is true. I just don't have that much
experience.)

It is not a crutch for lack of skill, like many people treat it. In fact you still have to be
very aware of everything from the hardware on up if you want to have quality software.

What I can say is that I've used plenty of python things that were faster then plenty of C++
things, even though that's usually not the case. Generally they crash much less and don't have
memory leaks, which is usually the case.

*shrug*

Offtopic: Python

Posted Aug 15, 2008 17:06 UTC (Fri) by drag (subscriber, #31333) [Link]

> Such as programming in python-C hybrid languages like Cython or Python

Oops. I meant Cython and Pyrex

Offtopic: Python

Posted Aug 15, 2008 18:15 UTC (Fri) by rwmj (subscriber, #5474) [Link]

I seem to have touched a nerve there. I now program almost entirely in OCaml, which gives me the real world stuff (loads of libraries etc), performance very close to C, low memory usage, proper error checking in the compiler, terse code, rapid development, etc. etc. In other words, all the advantages of Python, plus the advantages of modern languages, without having to wait for some far-off LLVM project to make Python fast.

Rich.

On topic: using collections, not mis-understanding the dashboard

Posted Dec 19, 2008 8:55 UTC (Fri) by grahamperrin (guest, #55680) [Link]

> their UI needs to be re-thought: It assumes you always want to copy
> items instead of move them to new categories. If you create an item
> and immediately delete it, you'll later find another copy in the
> "desktop" view.

Correction: _you_ assume that you always create items in the dashboard.

This is not a criticism, I do understand your misunderstanding of the UI ;)

Clarification:

1. select (click) a collection
2. create a note, within or without the calendar.

Result:

You will _not_ later find another copy of your item in your dashboard.

----

If you later copy something from a collection to your dashboard, it will remain in your dashboard
for as long as you want it in your dashboard.

I suspect that for some newcomers to Chandler Project:

* Chandler Hub is a more graceful introduction than Chandler Desktop.

The Hub encourages (currently, forces) users to think in terms of collections.

I will make my suggestion to the chandler-users list.

Everyone: re http://chandlerproject.org/mailinglists#TableOfLists please note that you may
address the list without subscription.

Kind regards
Graham

My misunderstanding! But thought-provoking

Posted Dec 19, 2008 9:05 UTC (Fri) by grahamperrin (guest, #55680) [Link]

I am wrong!

Sometimes it helps to think aloud (write) before I realise such things.

Indeed, this behaviour is interesting.

My first guess:

* it's not usual to delete some thing.

More usual:

* change the nature of the thing.

Changing its nature may be:

* triage to: done
* triage to: later
* add to calendar, or remove from calendar.

Let's rewind.

Q: Why did you create the item? (If it wasn't a note, task, event, whatever, then what was it?)

The question of most relevance:

Q: Why did you immediately delete it?

Reasons for immediately deleting something

Posted Dec 19, 2008 9:09 UTC (Fri) by grahamperrin (guest, #55680) [Link]

In testing: I might wish to immediately delete some thing that is not real.

In real life: I add real things to Chandler.

I suspect that this workflow issue is perceived only when working with items (notes, events, tasks,
whatever) that are for test purposes, not for real.

If what you entered in Chandler was a passing thought, worthy of noting, even momentarily:

* allow yourself that thought.

Your thought was real. In Chandler, mark your note of that momentary thought as:

* done.

Offtopic: Python

Posted Aug 25, 2008 10:15 UTC (Mon) by pboddie (subscriber, #50784) [Link]

If it was in C++, bah, you get compilation error immediately. But in Python the program would happily work ever after, until some day the thing would finally go there and explode.

Of course this kind of thing never happens with C++ programs, oh no! I've never seen the KDE crash dialogue from a C++ program ever!

I don't like how it turns out in reality, though, because what we have as a result seems to me to be more like "more code done by less competent people".

And thus we reach the heart of this critique: people who choose not to use statically-typed systems programming languages are not "übercoders" and must thereby form a queue at the "script monkey" counter.

While Python is more powerful than that, I'd still rather not see it being used to create programs for mainstream desktop use, although I think it's ok to use it in dedicated environments with known resources, like web development (whether this is beneficial or wasteful is up to the producer to decide, I as the consumer wouldn't care much).

What's fascinating is seeing desktop developers with the kind of attitude exhibited here implement their daemons and services listening on sockets with a level of robustness that would fall short in most Web application deployments, with the code typically wrapped up in monolithic bundles which typically need a big recompile after the most trivial adjustment, frequently architected with dubious integration to the user interface, thus keeping the oft-stated holy grail of component-based desktops as distant as ever. All this hardly makes the "mainstream desktop" development experience more pleasurable, which is why languages like Python seem to be gaining support in the big two free desktops despite the systems programming snobbery present in the upper echelons (especially of the one whose name begins with K).

Chandler finally reaches a 1.0 release

Posted Aug 15, 2008 14:34 UTC (Fri) by k8to (subscriber, #15413) [Link]

You won't use a program because its developers don't drink the same kool-aid as you.  OK.

KDE Kontact (Chandler finally reaches a 1.0 release)

Posted Aug 14, 2008 12:45 UTC (Thu) by ber (subscriber, #2142) [Link]

I think it is good to have more solutions, so I wish Chandler to gain some momentum. (Disclosure: I am the Kolab coordinator, which used KDE Kontact as main native client.)

As for problem reports, the enterprise35 and enterprise4 lines of KDE Kontact are geared towards enterprise use (suprise) and reports in the PIM functionality for Kolab are also welcome at www.kolab.org where we appreciate well written problem reports.

Chandler finally reaches a 1.0 release

Posted Aug 15, 2008 7:58 UTC (Fri) by aleXXX (subscriber, #2742) [Link]

In general we (KDE) don't just delete bugs.
There was talk about deleting all open arts bugs, since this is basically 
unmaintained since some time already and doesn't exist anymore in KDE 4.

There is a team of people going through bugs.kde.org and checking whether 
bugs are still valid and close them if not.

Sometimes bugs are closed if the reporter doesn't respond anymore and the 
developer can't reproduce the problem.

I don't know your specific case, but in general, we don't just delete bug 
reports.
You wrote "talking about simply deleting". So they were actually not 
deleted ? Maybe just somebody had a bad day when proposing this.

Alex

Chandler finally reaches a 1.0 release

Posted Aug 17, 2008 11:09 UTC (Sun) by BlueLightning (subscriber, #38978) [Link]

I remember the proposal you refer to - it was suggested just over a year ago in one
person's blog. However, the proposal was not as you state to "delete all submitted
bugs" - the proposal was to close all open bug reports for previous versions of the
software. The idea was that users could reopen issues if they could still reproduce
them. It was suggested because at the time the KDE bug database was clogged with
a huge number of bug reports, including many duplicates and ones that had already
been fixed; so much so that seemed like an impossible task to go through them all.

Now personally, I don't agree with this idea either. However it's important to point
out that it was most definitely *not* put into effect, and it shouldn't therefore be put
forward as a reason not to use KDE. This was all before the massive bug triaging
effort that has gone on in the last year which has improved the situation markedly.
IMO, KDE has shown that it does care about bug reports and it now does have
processes in place to deal with them effectively.

Chandler finally reaches a 1.0 release

Posted Aug 21, 2008 10:05 UTC (Thu) by endecotp (guest, #36428) [Link]

> the proposal was to close all open bug reports for previous versions 
> of the software. The idea was that users could reopen issues if they 
> could still reproduce them.

Mozilla did something like this; they closed all reports that had not been touched for more
than some longish period of time IIRC.  This included a few that I had reported, and which had
not reached the top of anyone's to-do list.  It did not make me feel as if my contribution was
valued and I would strongly discourage other projects from adopting the same approach.

Chandler finally reaches a 1.0 release

Posted Aug 21, 2008 22:15 UTC (Thu) by Sutoka (guest, #43890) [Link]

Good news! KDE didn't.

Chandler finally reaches a 1.0 release

Posted Aug 22, 2008 0:57 UTC (Fri) by roc (subscriber, #30627) [Link]

All you had to do to keep the bug alive was post a comment to it. If you couldn't be bothered
to do that, I guess it wasn't that important.