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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
