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
