[Chandler-dev] Future of redirectTo?
vajda at osafoundation.org
Wed Jul 26 03:12:10 PDT 2006
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
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
> 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.
More information about the chandler-dev