Re: [Chandler-dev] Post-1.0 Chandler Desktop Rearchitecture Project

Grant,

I agree with your point on focusing the rearchitecture effort on a
minimum amount of code that will give volunteer developers a solid
foundation to do the rest.  But I would put forward a slightly different
definition of what that minimum is: How about initially implementing as
little of the UI as possible and putting the bulk of your effort into
the Domain and basic Storage layers?

This would give us a working, well-tested Chandler "engine" that could
do CRUD operations on notes, tasks, and calendar items, plus sharing and
a callback mechanism for periodic tasks and reminders.

Interested plugin developers would then have the option to write
alternate Chandler UIs.  For example, I'd be interested in exposing a
DBus interface to Chandler, running it headless, and then using a
collection of desktop widgets for viewing the calendar, quick entry,
etc.

Davor


On Thu, 4 Sep 2008, Grant Baillie wrote:

> 1.0: What can we achieve from here?
> -------------------------------------------
> Basically, continuing down the pilot project path (i.e. filling in the
> pieces of a lookalike of the current app) doesn't really make sense, because
> it would lead to an improved (i.e. more tested/testable) version of the
> Chandler 1.0 app, but without #2 in particular, we would still face similar
> reliability challenges as before.
>
> Another consideration is that our organization and target audience have
> changed considerably since last year. Rather than having a large paid staff
> to port the code, we will be relying on more limited resources, and
> ultimately the goal is to have the code live on as a volunteer-run project.
>
> So, it makes sense to implement the original rearchitecture goals, (i.e.
> 1--3 above), while not necessarily focusing on a complete reimplementation
> of the current Chandler. In fact, leaving out features, or implementing
> them minimally can be seen as creating opportunities for volunteer
> developers. For example, only supporting sharing via the Hub leaves it
> open to others to add support for other Cosmo servers, or for CalDAV in
> general, or for particular Atompub-based servers.
>
> With this in mind, a goal that Jeffrey, Phillip and I agreed would be
> achievable using OSAF's remaining paid staff time is:
>
> Achievable Goal
> ~~~~~~ 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> **Create fully-tested interaction, domain and storage layers for Chandler:**
> This would include support for list and calendar views, stamping and the
> detail view, but would not include support for email/sharing.
>
> Besides achievability, this will will also provide promise that the full 
> rearchitecture is feasible. It will also leave room for outside developers to
> volunteer, and/or build custom applications.
>
> As mentioned earlier, there is flexibility as to what we implement
> once the first three or four items above. As a result, we can envision:
>
> Possible Different Goals
> ~~~~~~ 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Here are a couple of possible different routes we could take:
>
> **Sharing/"Chandler Lite":** Cut back, say, on some calendar features, but
> on a full application (i.e. up to presentation layer) that can sync a task 
> list
> with Cosmo.
>
> **Calendar UI:** Implement enough of a calendar presentation layer to allow
> other developers to work on a small, self-contained calendar (including a 
> detail view).
>
> There is also a parallel view of the rearchitecture,
> where we can look at user-level features that can be omitted in
> a first pass at either the interaction or domain layer. (Examples
> might be the minicalendar or preview area in current Chandler). This
> should obviously be discussed separately, especially once the basic
> infrastructure is in place.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev