On Aug 10, 2009, at 5:12 PM, Shai Erera wrote:
Maybe we should follow what I seem to read from Earwin and Grant - come up w/ real use cases, try to implement them w/ the current API, then if it's impossible, discuss how we can make the current API more adaptive. If at the end of this we'll get back to the new API, then we'll at least feel better about it, and more convinced it is the way to go.
Well, I have real use cases for it, but all of it is still missing the biggest piece: search side support. It's the 900 lb. elephant in the room. The 500 lb. elephant is the fact that all these attributes, AIUI, require you to hook in your own indexing chain, etc. in order to even be indexed, which is all package private stuff. It's not even clear to me what happens right now if you were to, say have a Token Stream that, say, had only one Attribute on it and none of the existing attributes (term buffer, length, position, etc.) Please correct me if I am wrong, I still don't have a deep understanding of it all.
Honestly, though, it really gives you very little over the current, well functioning payloads capability other than stronger typing, the ability to pick only those attributes that you want indexed (in theory) and a byte (or so) of savings per any token that has a payload, and we _HAVE_ right now, search support for payloads.
Oh, and now it seems the new QP is dependent on it all.
