The Chandler Project is pleased to announce the 0.14.0 release of Chandler Server (Cosmo)!

Chandler Server is a server and Ajax web UI for managing and sharing calendars, events, and tasks. It implements open data standards including CalDAV, WebDAV, Atom, and Atompub.

This release primarily consists of an update to Dojo, the Javascript toolkit used to build the Chandler Server Web UI. Dojo’s 0.9 release was essentially a complete rewrite, and involved a large number of core API changes. Changes to our codebase have been similarly numerous. We are currently using Dojo 1.0.2, and do not anticipate upgrades with as significant consequences in the future.

More information on Dojo, including comphrehensive information about changes introduced in its 0.9 release, can be found at:

http://dojotoolkit.org

Chandler Server 0.14.0 is available for download as a ready-to-run bundle at:

http://chandlerproject.org/serverdownload

and the source code is available from subversion at:

http://svn.osafoundation.org/server/cosmo/tags/rel_0.14.0

Send us feedback at the open mailing list (no subscription required):

chandler-users@osafoundation.org

We look forward to hearing from you!

The bugs fixed in this release include:

• #11607 Upgrade to Dojo 1.0
• #8499 Subscribe/unsubscribe to a collection on web UI
• #11351 Move client collection addition/deletion to atom api

The Chandler Project is pleased to announce the 0.13.0 release of Chandler Server (Cosmo)!

Chandler Server is a server and Ajax web UI for managing and sharing calendars, events, and tasks. It implements open data standards including CalDAV, WebDAV, Atom, and Atompub.

This release includes a major security fix as well as a small amount of minor bug fixes. The focus for this release was to fix the security hole present in prior versions that allowed users to gain write access to items without a read-write ticket. Part of this fix required changes to the desktop client, so upgrading the server to 0.13.0 will require upgrading Chandler Desktop to 0.7.5 in order to support certain features (sharing items in multiple collections). It is strongly recommended that the desktop client be upgraded to 0.7.5 when upgrading the server to 0.13.0. Chandler Desktop can be downloaded here: http://chandlerproject.org/Projects/DownloadChandlerDesktop

Chandler Server 0.13.0 is available for download as a ready-to-run bundle at:

http://chandlerproject.org/serverdownload

and the source code is available from subversion at:

http://svn.osafoundation.org/server/cosmo/tags/rel_0.13.0

Send us feedback at the open mailing list (no subscription required):

chandler-users@osafoundation.org

We look forward to hearing from you!

The bugs fixed in this release include:

• #11867 fix items in multiple collections security hole
• #11794 support for PostgreSQL in migration tool
• #10814 Can’t update an item that isn’t owned by user from webui
• #11779 changing calendar selection while looking at future weeks resets view to this week without grabbing this week’s elements
• #11797 Chandler requires JVM properties to be set
• #11641 HCalendarParser broken when ical4j.relaxed.parsing is set
• #11863 updating item using DAV results in owner always being set
• #11931 Can’t access account browser for any of my collections
• #11909 hibernate session not getting flushed after optimistic locking failures

There was a minor change to the database schema for Chandler Server in version 0.13.0. Instructions for upgrading from previous versions of Chandler Server can be found at: <http://chandlerproject.org/Developers/ServerBundleInstallation#Upgrading%20from%20previous%20versions>
Please remember to backup your database before attempting migration!

For the past three years Google has run an outstanding summer program for students
interested in becoming involved with open source software development.
Summer of Code offers students a chance to
develop relationships with living, breathing software communities by coordinating with
as many as 130 organizations and 900 students on 3 month software projects.
Stipends
are provided to both the mentor organizations and students, making it a very sweet deal
from almost any angle.

As we have in the past, OSAF will be participating in SoC as a mentoring organization this
year. A full list of projects we believe will be both useful to the project in the long term
and stand a high chance of being included in our code base in the short run can be found
here, but
as in past years outside proposals are more than welcome.

Comprehensive information about this year’s program, including important bits like
eligibility
and application instructions
can be found on the the official
FAQ. Student
applications will be accepted from March 24 - March 31, so now is the time to find
a project and put together a solid proposal!

As always, feel free to ask on one of the Chandler Project
mailing lists
or in #cosmo or #chandler on irc.freenode.net for more information.

Interoperability is an important part of the Chandler Project vision.

Chandler is about trying to match the way people really work. And everyone uses lots of tools to get their job done. One of the first things people want to know when considering trying out Chandler software is “Will it work with what I already use? Can I switch back if I don’t like it? Will it work with the tools that friends of mine use?”

We believe the answer to all these questions is “YES”! You can safely and productively start using one or more of the Chandler Project components on top of your existing toolset. Go ahead, try it out! Read more below to learn the details.

For a bullet-list summary of our best-available notes on specific applications and which features are supported with each, see our interop overview.

Import/export

The gold standard of calendar transfer is the “ICS” file (in iCalendar format). Most calendar and task list applications support both import and export of ICS files.

You can try out Chandler Desktop without switching from your current setup. Just export one or more ICS files from your current application, then import those files into Chandler Desktop (continuing to use your current app). To switch over permanently, just export+import again a final time!

If you later decide you’d like to change again, you can export ICS files from Chandler Desktop or Chandler Hub, using those files for import into a wide variety of applications.

We’ve seen import and export work for Outlook 2003/2007, Mozilla Lightning/Sunbird, Apple iCal, and others; it should work with a great many apps, probably yours included.

Note that Outlook doesn’t export full information by default; we’ve found this $10 application from littlemachines produces high-quality exports from Outlook that work well with Chandler Desktop.

In practice, doing ICS import/export can have gotachas. Not all application combinations/roundtrips are 100% perfect. We urge you to keep backups and try out import/export before committing your important data to any application. In Chandler Desktop, we’ve spent a lot of time tuning our import/export routines to handle as many variants and details as we can. Chandler Desktop properly handles events, tasks, timezones, recurrence, and other details. Please report any import/export problems you encounter.

We’ve put together some additional information about import/export with Chandler Desktop specifically, so check that for additional hints and notes.

Synchronization

ICS import/export is great for transferring your data between apps, but it’s a manual process not suited to keeping multiple applications in sync. Usually when you import a data set, your app will overwrite changes you may have in your local copies of those events. It’s hard to make changes in two separate apps.

Chandler Desktop and Chandler Hub both support multiple network sync protocols. Where other applications (Outlook, iCal, etc) overlap at least one of these protocols, interoperability is possible on at least some level.

One main idea to keep in mind when thinking about these various systems is whether a scheme is “read-only” or “read-write” (ie, bidirectional). It seems like read-only (or 1-way) interoperability works more reliably today, but protocols like CalDAV promise a new era of real-time, 2-way synchronization of calendar data between lots of free and for-pay applications and web services.

The big news is that you can do 2-way/read-write calendar and task synchronization today, both privately and shared with other people. Here’s a list of the main ways to do that, based on Chandler Project software.

Webcal, 1-way sync

The most simple network protocol is to take an ICS file (see above in import/export) and post it to the web, so various apps can download it (redownloading to check for changes periodically). This system is called webcal.

Chandler Desktop works great for subscribing to a number of public webcal URLs and overlaying them all on one canvas. This is a great way to keep track of lots of calendars.

If you store any events/tasks on Chandler Hub, then you can login to get a URL that you can enter into the right spot in Outlook, Apple iCal, Google Calendar, Lightning/Sunbird, Evolution, Zimbra, and many other apps to synchronize that Hub calendar with your app. This is always a read-only/1-way procedure.

Using webcal, in Outlook 2007, you can overlay say personal or family Hub calendars on top of your Exchange/Outlook calendars you use at work. (Look for “Internet Calendar” features in Outlook’s help.) If you make a change on the Hub or Chandler Desktop and then synchronize, you’ll see that change in your work Outlook’s display.

You can also subscribe to Hub calendars in Outlook 2003, but only view the calendars side-by-side. Other apps like iCal, Lightning/Sunbird, Google Calendar, and Evolution all support overlaying the Hub calendar with other calendars.

Many applications, Outlook included, can also publish a webcal calendar to a web server. You can use Chandler Hub as a destination server for most of these webcal-publishing apps. This works, but please note this does not provide a web UI for that calendar, and it’s again a 1-way publication. The original application will very likely not detect any changes made to this webcal file on the server.

Webcal, 2-way sync

Chandler Desktop can also do 2-way synchronization via webcal. Most applications treat a webcal file as read-only or write-only, but Chandler Desktop will check for changes in a webcal file it is monitoring and integrate those changes. If used with another application that also checks for changes, you get 2-way synchronization. We know Lightning/Sunbird does this (though you might chose to use CalDAV to synchronize instead).

CalDAV, 2-way sync

CalDAV is an emerging standard protocol for open calendar exchange. It’s not a protocol that’s used directly between two clients (like ICS files are), but rather defines a calendar server to which multiple clients can subscribe and synchronize. Chandler Hub also provides a read-write web UI to any calendar you store or use in your account.

The Open Source Applications Foundation via the Chandler Project was an early supporter of CalDAV. Together, our Chandler Desktop application and Chandler Server server product are some of the oldest and most mature implementations of the CalDAV standard and we plan to continue that support.

Chandler Hub is, as far as we know, essentially the leading free CalDAV service offered to the public. Given a fully-cooperating CalDAV client (Lightning/Sunbird, iCal 3.x, and Evolution all cooperate to various degrees), you can use these other clients regularly or occassionally and even use Chandler Desktop for advanced work (like sharing a single item between multiple calendars).

Chandler Desktop can subscribe to and publish a collection (calendar+events) to any CalDAV server (Apple Calendar Server, RSCDS, Bedework), or actually any WebDAV server (Apache mod_dav, .Mac, etc). Both of these mechanisms support bidirectional (read-write) synchronization, so multiple applications or people can all create, edit, and delete events and tasks any time they want, using the application of their choice.

iCal 3 (in Apple 10.5 “Leopard”) is a great new CalDAV-using PIM client. You can use it to make changes to your Hub collection, and still be able to use the Hub web UI to make changes from anywhere. Note that iCal 3 supports read-write calendars only to calendars in your account. Chandler Desktop and Chandler Hub let you subscribe to shared collections owned by other users with full read-write access.

Email integration

Chandler Desktop is not a complete email client; it is rather intended to complement your existing email client. The mechanism we use is to create dedicated Chandler folders on your IMAP server. Using your regular email client (Outlook, Thunderbird, Mail.app, Evolution, etc), you just drag an email from your inbox into a Chandler folder, where the message will be parsed for event, task, and other information.

You should also be able to send email update of items from Chandler Desktop using just about any outgoing mail server available. Events emailed this way appear as ICS attachments. We’ve tested Exchange, Postfix, Gmail, Yahoo mail, and Hotmail/MSN among others.

A month ago, I wrote about next steps for the Chandler project after our reformulation as a smaller, more agile team. Since then we’ve made the plan concrete — here is a summary of the goals and a few pointers to specific work queues.

Mimi described the goals nicely in a post to the chandler-dev list…

1. Get Chandler in front of more users, aka: Make it more viral.

Product changes:

* Item sharing: a new workflow to use the web to collaborate on just one item. We’ll “widgetize” this functionality, making it available in other contexts like iGoogle or on an iPhone.
* Improve web UI “ticket views” so subscribers can more easily subscribe to collections in applications they already use
* Improve existing use cases for iCal and Lightning users (sharing with Chandler users, using Chandler Hub)

Marketing and Evangelism:

* Improve our pitch, improve our web presence
* Better demos, user testimonials
* Reach out and talk to people about Chandler in other spaces

2. Make Chandler more appealing to new users, aka: Reduce barriers to getting started.

Reduce the number of new concepts users need to understand in order to get started:

* Pare down UI, de-emphasizing email UI
* De-emphasize notion of “Item” and replace with “Note”
* Remove explicit “Task” and introduce “Star”

Improve the web UI experience for people not using Chandler desktop (iCal/Lightning or Hub only users):

* smooth out sharing workflows
* auto-triaging CalDAV events
* make Notes field in detail view more usable

3. Make it easier for new users to ramp up to using Chandler every day.

Add two additional “widgets” with features that allow people to use Chandler in other contexts:

* Notifications: Users can send themselves or others notifications about changes to shared collections. This also counts towards the first goal, as it allows current users to share some Chandler functionality with other people. Notifications will be available first as an iGoogle widget (and potentially other similar contexts), and eventually also as email, SMS, or IM messages.
* Quick Entry: this widget will allow users to enter items into Chandler Hub from other contexts: iGoogle, iPhone, OSX and Vista widgets. Eventually we’d like to allow similar functionality through forwarding email to a particular address.

Work Queues and Releases

The work described above has been broken down into tasks and bugs and is prioritized into two work queues, one for the desktop and one for all of the web related work. Grant is marching down the desktop queue while everyone else tackles the web queue. We meet daily to cover progress, adjusting the work queues if priorities change. (Mockups and specs for the new widgets and web UI changes are also linked from the web queue.)

* Web Work Queue
* Desktop Work Queue

The plan is to do a desktop release and a server release once a month. Usually these won’t need to be coordinated — though in this next round we have a security bug that involves both.

Phillip’s work on the desktop rearchitecture is the exception. He’s posting about his work over on the PEAK list. We may move Chandler desktop over to this architecture after the 1.0 — we’re waiting to see how this plays out to make the call on that.

Milestones

We plan on hitting a few major milestones by early summer — these are the big goals we are shooting for:

* Web Widgets: Quick Entry, Notifications, Item Sharing — we’d like to have these deployed in a few contexts.
* Desktop 1.0: We’re pretty close to releasing a 1.0 desktop. Prior to launching this we want to make sure some web UI improvements go up on the Hub, and make some changes to the website.
* Server 1.0: With some security fixes, authentication work, and a few other items (e.g. the ability to disable account signups), we should be able to release a 1.0 for people who want to run their own server.

We don’t need to coordinate all of these milestones — we may hit some more quickly than others.

Changes to the Plan

We were thinking we’d put minimal investment into the existing web ui, figuring that we’d do a better job on the web use cases we want to hit with the web widgets. Once started thinking through both the web and desktop use cases, we realized we really do need to make some investment in the existing web ui. We’ve added web ui bugs to the web queue.

We decided to put off working on a Thunderbird plugin, for two reasons: (1) after doing a bit of research it was starting to look like a more sizable investment than we initially thought and (2) we worried about having too many projects.

The Chandler Project is pleased to announce the 0.12.0 release of Chandler Server (Cosmo)!

Chandler Server is a server and Ajax web UI for managing and sharing calendars, events, and tasks. It implements open data standards including CalDAV, WebDAV, Atom, and Atompub.

This release supports a standalone WAR form of Cosmo ready to drop in to an existing Tomcat installation. A security issue allowing unauthorized access when a collection had been shared was fixed. A number of smaller bugs have also been fixed for Unicode usernames, error logging, and the calendar web UI.

Chandler Server 0.12.0 is available for download as a ready-to-run bundle at:

http://chandlerproject.org/serverdownload

and the source code is available from subversion at:

http://svn.osafoundation.org/server/cosmo/tags/rel_0.12.0

Send us feedback at the open mailing list (no subscription required):

chandler-users at osafoundation.org

We look forward to hearing from you!

The bugs fixed in this release include:

• #10816 Document how to deploy Cosmo into Tomcat
• #11101 unicode characters in username break admin ui
• #11442 overlaid event continues to be displayed in the color of the unselected calendar
• #11481 deleting account not working exactly as expected
• #11487 including records with dulicate icaluids succeeds
• #11554 Incorrect, possibly scary confirmation prompt when deleting subscriptions
• #11591 MC protocol needs its own security component
• #11754 retryfilter no longer works for dav
• #11755 server trying to update item in read-only service call
• #11757 invalid http method causes errors in log
• #11572 when allday is checked, time should be disabled
• #11721 February 29th not displayed in 2008

There was no change to the database schema for Chandler Server in version 0.12. Instructions for upgrading from previous versions of Chandler Server can be found at: <http://chandlerproject.org/Developers/ServerBundleInstallation#Upgrading%20from%20previous%20versions>

Last week the staff got together in person and took a critical look at where the project is now and what we want to achieve in the next year.

We asked ourselves a series of questions, including: “We have some successful, enthusiastic users who rely on Chandler daily: how are they using it? What are their success stories? How can we build on that and grow the user base?” and “Why do we only have 100s of unique desktop users syncing to the Hub daily when many 1000s of users have downloaded the desktop?”

Looking at users who *are* successful and potential users who run into difficulties, we had this insight: Chandler succeeds at meeting the needs of users who are tracking ‘knowledge work’. What do we mean by this? We’ve observed people tracking ideas and questions for tasks they need to do — the kind of things people otherwise might jot down in notebooks, on scraps of paper or in text files. They selectively add important email messages to Chandler (the ones they might have flagged if they were only using their email client). They share collections of these items with other people as they develop an idea, using Chandler to record the ‘knowledge’ about a shared project. Quick item entry, stamping items onto the calendar or a task list, and items in multiple collections are all signature features that help users evolve their ideas into tasks and projects. While the design includes tasks and a hard calendar landscape, Chandler is not oriented around calendaring per se or around a complicated task and project landscape with many dependencies. We don’t have enterprise scheduling features, for example, or task and project dependencies. Instead of adding more features for calendaring and task/project management over the next year, we’d like to build on Chandler’s more unique strengths, excelling at meeting the needs people who currently find Chandler compelling.

Of course, many users who *do* have similar needs to the successful users run into barriers when trying to use Chandler. The application is too slow for their hardware, they are overwhelmed by non essential functionality visible in the application, they don’t know how to get started, they run into a roadblock when creating an account, etc. We want to remove these barriers.

The flip side of this is that some people who have been drawn to the project are really *not* target users. Chandler doesn’t meet their needs because Chandler is not designed for them. We just don’t have the resources to make all of these people happy — we really do have to focus. More on this in the “what we are not doing” section below.

Another idea that came up in our discussions: we want Chandler to be more viral. We want Chandler to be easy to explain to others. We want Chandler to be found in contexts where people are already spending time. We want Chandler to be of great use to the individual using Chandler on their own, and to be even more useful as that user pulls in other people to collaborate. We want happy users be successful evangelists for Chandler.

What we are doing next

We made some important high level decisions about what we’re going to be focusing on in the next year, and in particular for the next 3-4 months. It was most concrete for us when we discussed exactly what each person would be working on (in particular what each developer would be working on), so I’ll use that to frame our strategy.

Grant Baillie: Incremental progress on the desktop. We decided that we can’t stop and take time out to rewrite the desktop or build a complete web based home for our target users, so that means continuing to maintain the current desktop code base. Grant will focus on bugs and small feature changes that remove barriers for users who otherwise would value Chandler’s feature set. We are not far from a 1.0 version of the desktop. One of the first projects that Grant is working on is a pass at simplifying the UI by removing rarely used email functionality — reducing the number of new concepts that users need to get started.

Travis Vachon and Jeffrey Harris: Web widgets. We’re turning our focus on the web away from replicating the desktop functionality, and toward making Chandler more viral and better at facilitating idea gathering and collaboration for our target users. Travis and Jeffrey are going to build web widgets that might be deployed in different contexts — iGoogle, Facebook, on an iPhone, etc. Widgets will give read/write access to a particular item (instead of a whole collection), allow users to search for a particular item, allow quick entry of items, etc. We’ve started the design work on the chandler-dev list. One requirement for the web strategy is that these widgets should be compelling to a new user who does not use the desktop, in addition to providing features that complement the desktop. Eventually, the widgets can be building blocks for developing out that web based home for our target users.

Brian Kirsch: Thunderbird plugin. Brian has already blogged about this idea; we’ve decided to proceed with it. We think it will be a great way to introduce Chandler ideas to a new audience.

Jared Rhine: Email related features on the Hub. Jared will explore adding email notifications/reports from the service, and email as a way of entering data into the service. Again, these features are a way of making the Hub more viral — data access from other contexts where people spend their time. This work is in addition to Jared’s many other responsibilities (managing the Hub service, build and release management, etc.).

Randy Letness: Chandler Server improvements and support for web widgets. Randy will continue with security work that has long been planned, as well as server support necessary for the new web widgets.

Phillip Eby: Desktop rearchitecture. We will continue to make a modest investment in the rearchitecture project that we embarked upon last year, as the rearchitecture is our path to really solving desktop performance problems. The rearchitecture will also provide a much better platform for other developers to contribute to the project.

Mimi Yin: Product design and strategy. Web strategy and web widget design, Thunderbird plugin design, desktop prioritization, project website improvements, etc.

Sheila Mooney: Evangelism strategy. Develop a pitch and a demo, meet with stakeholders, etc. One of the barriers for potential users and partners is really a marketing barrier — helping people understand what Chandler is intended for.

My job is to manage the project overall and give the project its best shot at thriving beyond the end of the year.

What we are not doing

We are not trying to be an open source Exchange/Outlook competitor. While this would be a worthy goal, it is not our passion and we don’t really have the right product or organization to pull this off. It has been a misperception in the press that this has *ever* been our goal — probably because so many people want an open source competitor to Exchange/Outlook. We have not designed Chandler for enterprise calendaring. Actually, the Microsoft product with the most overlap with our design objectives is probably OneNote.

Being a CalDAV reference implementation is not a priority. We believe that calendaring standards are important and hope that they are adopted in the world, and much of OSAF’s energy in previous years was directed at making that a reality. With our current need to focus, however, our strategic objective wrt calendaring standards is to be able to interoperate with popular clients (e.g. iCal and Lightning). For this reason and because we are not trying to do enterprise calendaring, we will not be implementing CalDAV scheduling.

We are not trying to be a GTD specific tool. Yes, we paid a lot of attention to GTD as we were designing Chandler and we were inspired by ideas from GTD. We also looked at how people who have never heard of GTD really use their inbox to manage their world, and taken inspiration from that as well. When getting into the specifics of Chandler’s design, we focused on user scenarios and workflows that would make our target users successful — not necessarily designing to GTD processes. We’ve recently taken a critical look at how well Chandler meets the needs of someone following the GTD process strictly. In doing so, we realized that we didn’t want to prioritize staff time to work on changes that would make Chandler a GTD specific tool, and that Chandler’s philosophy is different enough from GTD that it would be misleading to call Chandler a GTD tool. We’ll need to change our messaging — our landing page, blog and other places that refer to GTD. That said, we recognize that some developers are interested in features that would help people use Chandler for a GTD process, and we encourage anyone who wants to contribute code for such features.

We are not going to add full email functionality to Chandler desktop, or contacts (at least not in the next year, not on OSAF staff time). Yes, we know that many people want these features, and we’d love to design them and implement them if we had the resources, but we don’t have the resources in the next year. Again, we’d *gladly* accept code contributions that implemented these features, or additional funding to implement them. We are willing to spend time to help make people successful contributing code for these features (or other features that complement the current product).

To help focus as a team, we have consolidated our various mailing lists in the following ways:

1. Chandler-dev is now the working list for all things pertaining to the Chandler Project. This includes planning, design and bug prioritization for both Chandler Desktop and Chandler Hub as well as general interest topics like the project wiki, evangelism, community, and governance.

2. Cosmo-dev remains a separate list for those interested in just the server. Planning and project management discussions that used to happen on Cosmo-dev will move to Chandler-dev.

3. General, Design and Service-dev are now inactive. These conversations will move to Chandler-dev. If you are on one of these lists and want to continue following the day to day work of the project, subscribe to Chandler-dev.

4. Chandler-users will remain the best place for users to ask questions and report issues. Email us at chandler-users at osafoundation dot org.

5. Announce will continue to broadcast major releases and other newsworthy information.

All other public lists will stay the same.

We are also maintaining a Chandler Project collection where you can keep up with more day-to-day work. This is where we’re keeping track of feature ideas, upcoming blog posts and meetings.

View-only URL: https://hub.chandlerproject.org/pim/collection/f9fe3636-c489-11dc-dba3-f100459c9336?ticket=37960wr571

Finally, we will be making more use of the blog to discuss design direction, product strategy and to keep everyone abreast of project status and new releases.

Katie’s post OSAF 2.0 Team
seems like a good opportunity to introduce myself in this space. When I first joined OSAF
I was asked to do this by Pieter
Hartsook but a combination of a bad memory and busy schedule has kept this task triaged Later.

I’m originally from a small town about 45 minutes outside of Portland, Maine. My first brush with software development
came during the summer of 2006 when, alongside a 6 day-a-week summer camp job, I participated in Google’s inaugural
Summer of Code program. My project for the summer found me working with
the GNOME Project implementing an experimental “panel extension” system.

I found Chandler while looking for a Linux calendaring client during my senior year at Williams College
and after an internship on the Desktop team working on a project to better integrate the Twisted IMAP server into Chandler I was hired full-time
as a server/ web front-end developer.

Most of my work since then has straddled HTTP, working mostly at the protocol level on the server and client side, with occasional
forays down into the depths of our database layer and up to the shallow waters of user interface implementation. Most recently I’ve
been updating our JavaScript code to use the 1.0 release of the Dojo toolkit.

A second project I’ve worked on recently (alluded to in the title of this post) is the first of what I hope to be a series of
interesting hacks designed to expand Chandler into the maze of nooks and crannies that is contemporary personal information management.
One of the more important lessons I’ve learned while working in this space is that everyone has a different system
for tracking and managing the various things they want to accomplish both in work and in life. While semi-standard systems like Chandler’s
Triage Workflow and David Allen’s
GTD can help, even the most hard-core practitioners will make adjustments
to work with their own personal circumstances. As developers of software designed to
“serve the way people actually work, independently and together“, I believe it is our
job to lead the way in bringing our ecosystem to people’s real needs.

So without further ado, let me introduce chandler.el, a module for interacting with
Chandler Server using Emacs, a popular text editing environment.
Instructions for installing and using it can be found at the link above. The current implementation is decidedly rough, but is ready for
some real world use and feedback.

This offering is definitely on the techie side, but I hope it serves as a proof of concept for a general class of lightweight
applications that have the potential to bring Chandler to the system you currently use to track your life. There is currently
a discussion on chandler-users@osafoundation.org
in which I’ve solicited ideas for more applications like this, please feel free to chime in there or in the comments to this post
with yours!

In the future, updates about chandler.el will be posted mainly on my personal blog occident.us alongside information about whatever I happen to be working
on or thinking about at the time. If you’re interested in what I do, do check out that space.

Mimi and Katie talked in ealier posts about expanding the Chandler Universe
by developing a Plug-in for Thunderbird.

The plug-in would allow Thunderbird users to interface directly with the Chandler Hub.

Some of the current ideas on what actions the Thunderbird Plug-In would perform are:

1. Sync messages in IMAP Drafts/Sent folders with Chandler Drafts/Sent messages.
2. Stamp a message and add it to a list of collection(s)
3. Assign Triage status to message items
4. Map individual IMAP folders to collections
5. Receive notifications from Hub Service when:
a. New / Edited items in a collection
b. Items tickled to NOW

What features would others like to see?

Is the idea of a plug-in to Thunderbird useful to the Chandler User base?
Will a plug-in help attract new users?

If you have any suggestions for features that you would
like to see implemented in a Thunderbird plug-in now is the
perfect time to share them.