[Chandler-dev] Future of redirectTo?

[Phillip J. Eby]

At 06:09 PM 7/25/2006 -0700, Bryan Stearns wrote:
>There are a couple of things happening that are calling our 
>attribute-redirection strategy into question...
>
>- Bug 6387 (sorted index doesn't maintain sort) where we're trying to 
>index a redirectTo attribute. I'm not sure what exactly is happening, but 
>I can imagine: existing attribute redirection doesn't let the repository 
>know when a redirect-source attribute has changed, so that it can update a 
>redirect-target index.

Just as an FYI, we currently have about 35 "redirectTo" attributes.  Of 
these, 10 are redirecting to "displayName" -- and 9 times out of 10 it's a 
redirection from "about" to "displayName".

This suggests to me that we don't need displayName or redirection in any of 
those cases; we should just have an "about" attribute on ContentItem and 
let people set it as they will.

Nearly all the remaining redirectTo attributes serve to implement "who" and 
"date".  Again, this seems to suggest that simply having standard "who" and 
"date" attributes is a good idea, leaving it up to subclasses to set any 
alternate values.

I might be wrong, but it seems to me that if we abolished the 
"about->displayName" redirects and *reversed* the direction of the others, 
this would solve any indexing problems with the standard who/about/date 
attributes.


>- The dashboard spec calls for more-complex multi-attribute sorting on 
>some columns; some of the sorts call for collection indexes that will need 
>to consider attributes on items other than the one in the collection: eg, 
>when sorting the date column, an item needs to produce "the next 
>interesting datetime", which could be the startTime if it's an event, or 
>the datetime of the next tickler that's going to fire (and while the spec 
>only calls for one tickler per item for now, there'll be multiple ticklers 
>in the future).
>
>I don't have a solution to this (in spite of what John said in bug 6387), 
>but I'm writing this to start a conversation. Jeffrey had suggested using 
>onValueChanged methods to keep new just-for-indexing attributes updated.

I've suggested this also, as it should support highly dynamic use 
cases.  Kind of a STASCTAP solution ("simple things are simple, complex 
things are possible").


>  Andi suggested using some form of bequeathTo (the inverse of redirectTo?),

If I understand correctly, we should just be able to reverse the direction 
we're doing the redirects in.  Just give every ContentItem a who, date, and 
about attribute, then index those.  Let subclasses worry about how to get 
stuff in there.  In the simple case, they can define their alternate names 
(e.g. contactName, createdOn, etc.) as redirects to the base class attributes.

There is some overlap, I suspect, between all of this and 
stamping.  Presumably what values end up in the fields may be 
state-dependent on the active stamps, so it may require an extension to the 
new stamping protocol to allow delegating this computation to the 
stamps.  Annotations can have properties or __setattr__ hooks, so they can 
easily detect when a stamp value is changed and update the main 
who/date/about fields.