[Chandler-dev] Future of redirectTo?

[Andi Vajda]

On Wed, 26 Jul 2006, Phillip J. Eby wrote:

> 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.

I think this is correct.

>>  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.

+1

> 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.

If I understand the 'new' stamping correctly, it might allow us to make this 
new 'inverse redirectTo' or 'bequeathTo' more dynamic.

I should point out that 'redirecTo' is not as static as it seems since an 
attribute can be redirected via a chain of attributes such as 'about' -> 
'now.there.that.topic' where each intermediate value is an item that can 
change, ie, only 'topic' is completely static. 'bequeathTo', the inverse of 
'redirectTo' would be only as static.

Andi..