[Chandler-dev] Future of redirectTo?

[Grant Baillie]

On 26 Jul, 2006, at 03:12, Andi Vajda wrote:

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

This could be a little tricky, if you need to ensure that the correct  
stamp wins. For example, we might decide a mail message's "who" is  
what we want, even if that message is stamped as a task. If ordinary  
tasks use "requestee" (say) as "who", then if the user changes that,  
the task has to be clever enough not to change "who" when the mail  
stamp is present.

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

I think this means you can never 'redirectTo' an Annotation, FWIW  
(since the attribute names use '.', too). If this ever becomes  
necessary, I suppose we could tweak one implementation to be  
compatible with the other.

--Grant