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