[Chandler-dev] Reengineering stamping

[Alec Flett]

[I'm just sending this to the dev list because its more a rant/complaint 
about the state of the domain model than anything having to do with 
actual design issues]

Mimi Yin wrote:
> Hi Alec,
>
> I didn't mean to imply that the design needed to be mirrored in the 
> implementation. I was simply trying to re-state Jeffrey's 
> implementation proposals in terms of design in order to make sure the 
> implementation will meet design requirements.

Sorry, I was probably muddling things there - if anything I mean 
implicate engineering (including myself) for trying to model your 
designs too exactly - by reflecting the language of design too directly 
into implementation :) So I hope moving forward in the domain model we 
can be aware of this and tread more carefully.

For example, I am (like the "original implementors") still thrown off by 
your use of certain key words, for example 'schema':
> The goal is: *W**henever we ca**n* we should try to simplify the 
> schema so that users don't end up with a bazillion fields. If a user 
> wants to have more fields, they can always have them via user-defined 
> attributes. But the default should err on the side of too few, rather 
> than too many.
>
because again, on the implementation side, we have a very specific 
notion of the word "schema", which probably should have some of the very 
duplication you're trying to avoid. We have lots of fields that never 
even appear in the detail view because they are part of the internal 
implementation, but I think sometimes we read the above words and think 
"alright, mimi says simplify the schema!" when you don't care what level 
that gets implemented at.

(An implementation example: An Event-MailMessage probably does need 
distinct "attendees" and "To"/"From" attributes, but it should be up to 
the UI code to determine what to display when. The duplication is 
probably needed because functionally the data is used for different 
things internally. (such as composing an RFC822 header, or exporting to 
.ICS) The duplication is a semantic issue that should be reflected where 
the semantics matter (i.e. such as the UI) not at the domain model.)

I think its very tempting for us, as implementors to try to make an app 
have a "simple" implementation architecture by reflecting every semantic 
in the  the low level data model, so that the UI can just be "dumb" and 
merely be a direct reflection of the domain model. I think this is how 
"redirectTo" came about - its a horrible semantic that has gotten pushed 
all the way down into the actual behavior of the repository. Really, 
while the notion that 'who' means 'sender' in an e-mail needs to be 
recorded somewhere, the actual redirection behavior should probably be 
done by the table summary view, not the repository.

Alec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060315/595a75c0/attachment.htm