[Chandler-dev] [Sum] The Great Architecture Discussion of 2007

[Andi Vajda]

On Wed, 10 Oct 2007, Phillip J. Eby wrote:

> At 10:39 PM 10/9/2007 -0700, Andi Vajda wrote:
>
>> On Tue, 9 Oct 2007, Phillip J. Eby wrote:
>> 
>>> The thing is, once you look at this from the app layering perspective, the 
>>> mismatch between the relatively simple things the app is trying to do, and 
>>> the very powerful generality of the repository, becomes more apparent.
>> 
>> So, I ask again to the general readership of this list - Phillip, I think
>> your opinion is pretty clear - do we want to compile Chandler into a
>> "relatively simple" app like Mail.app or do we want to keep the "powerful
>> generality" part of the vision and implementation of Chandler when I joined
>> the project in 2003 ?
>
> This is both a false dichotomy and a red herring, because:
>
> 1. It is not an either-or choice, and
> 2. Nothing I have proposed removes any ability of Chandler to have "powerful 
> generality".
>
> In fact, the domain refactoring Grant and I are working on significantly 
> *improves* the generality of the application, as it decouples dashboard 
> information from content items, so that it's possible for plugins to have 
> "content items" generate an arbitrary assortment of dashboard entries.  The 
> same is true for reminders.
>
> (That is, we have a way to fully generalize recurrence and reminders, in a 
> way that's quite extensible and reusable by plugins, that the current model 
> does not support.)
>
> This is only one example of the many ways in which I expect Chandler's 
> current level of "powerful generality" to be expanded as a side-effect of the 
> refactoring.
>
> So, it would be helpful if you could clarify precisely what "generality" 
> you're referring to, that you're afraid we're losing.
>
> Note, too, that nothing that is being contemplated rules out the possibility 
> of having user-defined schema at a later date.  Nothing stops anyone from 
> writing a plugin that contains a static schema that meta-models dynamic 
> schema elements, for example.
>
> However, the reality of the project is that OSAF actually creating such a 
> plugin is out of scope for the foreseeable future, and was already declared 
> such two years ago.

All right, then. I'm wrong to be worried about the direction this 
re-architecture is taking. I'm afraid, I can't verbalize why, precisely, and 
be any more helpful to the conversations going on in this thread.

> And one of those reasons is that it's a silly thing to offer.  You're not a 
> samurai, so there's no need to commit hara-kiri just because some features 
> got re-prioritized.  Put the sword away, already, nobody is questioning your 
> honor.  :)

Silly ? For the past four and a half years, I've been under considerable 
pressure to deliver on a persistence model that I strongly believe in - that 
was chosen by OSAF way before I joined - to deliver I product and a platform 
that were core to the vision that started all this. Persisting objects, not 
data, and transparent persistence were part of this.

It is rather discouraging to be told after all this time and work that we did 
it all wrong, and that we have to start over and that we need to persist data 
instead of objects after all :)

Just like when you joined us, when you were already saying so, I offered you 
my job. You're again, even more forcefully this time, doing the same.

Again, I'm offering to yield as I don't see how I can contribute in an 
endeavour I don't believe in. It's not a matter of personal honor, please 
leave that aside, but a matter of fairness to the project and to myself.

I don't want to stand in the way of progress, in other words.

Good luck !

Andi..