I'm +1 on the pilot project. Here's my thinking...
The main objectives from the desktop team until the end of the year are
shaping up to be:
- Add a month view
- Iterate on the dashboard so that the triage features work properly and
are useful to individuals and small groups sharing a list of
tasks/items. (Falls under Mimi's "fix what's broken" list).
- Pilot project to connect to Exchange (more on this to come)
- Pilot refactoring project to illuminate the path to
scalability/performance -- strategically, be able to go for email and/or
other large data sets.
- Miscellaneous fixes for problems that block end users (again, falls
under "fix whats broken"). This includes a modest amount of interop work.
If we had unlimited resources, I'd have no hesitation in proceeding with
the pilot project. I know that Grant and Phillip have looked at this for
some time and I trust their judgment that this is the path to the best
architecture given our requirements at this point in the project. (I
know that some of these conversations have been private and not all of
you have the full picture of how they are thinking about it -- please
pipe up with questions and requests for more information if you want
more details. I'm not asking everyone else to "just trust them" without
a dialog.) The performance issues are systemic, we're not going to get
much further by just focusing on "speeding up" the repository. The pilot
project addresses problems that plague the overall architecture of the
application.
I am concerned that the architecture project takes resources away from
iterating on the dashboard/triage features, as we need to prove/disprove
whether or not these features are going to be compelling to people. That
said, I think the right thing to do is balance investment in "fixing
what is broken" with minimal new features and other experiments in
projects that will help us over the long term. The pilot project doesn't
threaten the short term work we are doing to iterate on Chandler.
Again, the architecture pilot project has my support.
Cheers,
Katie
Grant Baillie wrote:
Since the architecture thread got increasingly bogged down in some
specific and pretty low-level discussion of storage specifics, it seemed
like a good idea to outline specifically what it is Phillip and I are
proposing for a pilot project. Some of these details have been exposed
within the previous thread, but in the interest of transparency I'd like
to collect them here.
What we're proposing is, to devote approximately 6 person months(*)
(i.e. 3 people for 2 months, probably, or 2.5 people for ) to have the
following in place:
* Testable (and doc/unit tested) interaction model (i.e. "the app
without the GUI"). Includes:
* sidebar
* dashboard
* calendar (including recurrence)
* reminders
* triage
* Testable (and unit tested) domain model
* Testable presentation layer hooked up to wx
Subsidiary goals (i.e. things we are making sure we have a story for
while designing the code):
* Extensibility
* Scriptability
* Performance
Explicit non-goals:
* Persistence layer: i.e. not saving user data (import from a format
like .ics is possible, especially for performance testing purposes).
* Sharing/email import.
The lack of persistence is likely to be controversial in some quarters.
The above course is really based on the observation that the twin goals of
* removing persistence from CPIA
* separating out a testable 'app' layer
necessarily involve implementing extensive scaffolding to emulate the
existing repository usage (notifications, including collection
observation, for example). If our long-term strategic aim is to have at
least the prospect of attacking scalability and performance at all
levels, this path gives a clear picture of what the app requirements are
for storage. Said another way, it's a way to ensure that we can know
whether there are performance/scalability bottlenecks in what has been
termed the "app level", and to have specific performance goals for the
storage level (for which chandlerdb is an option).
--Grant
(*) a.k.a. "mythical man months"
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
