Adam Lally wrote:
On 1/2/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I wouldn't mind doing this as a first step, but I'm concerned about the
future. If we need to support this approach going forward, I would
prefer if we could answer the questions about the relation between the
CAS and CasViews first: how are indexes in the CAS related to indexes in
CasViews? If we're ok with maybe changing this again in the next
release, I'm ok with starting like this.
This proposal only has indexed in CasViews, not indexes that belong
directly to the CAS. (Unless you meant the deprecated index-access
methods on CAS that use the current view.)
I think this proposal also has one set of index "definitions", and each view
gets its own private set of index-instances for these definitions.
I would also like to figure out if there should be such a thing as
indexes that belong directly to the CAS ("global" indexes?), but it
seemed like we were too far from a consensus on that to get anything
done for 2.1.
I agree - we lack consensus here. My leaning is toward not having
"global" indexes.
We can always add additional methods to CAS (i.e.
getGlobalIndexRepository()) in a later version if we decide that's
right. And we probably can't redefine any of the existing indexing
methods on CAS without breaking a lot of code anyway. So it "smells"
like starting with this proposal will not get in the way of future
enhancements.
Will the methods not really associated with a CAS object (they are or
could be
static methods) still be on the CAS or CommonCas:
createFilteredIterator, getConstraintFactory, createFeaturePath,
createFeatureValuePath, and fs2listIterator
I suggest that the methods that belong in the CasView be left there
(deprecated)
to operate on the "current view":
get/set for Sofa things like DocumentText, SofaDataURI, etc.,
getSofa
getIndexRepository
getAnnotationIndex(type)
get/set associated with DocumentAnnotation (I think there one of
these per "view" - agree?)
add/removeFsTo/FromIndexes
Adam suggested that the methods that belong in the CAS for creating
FeatureStructures and get/setting their fields be
made to work in the CasView API, for convenience; I agree with that.
For things like createView and getView(String or FS) - I'm ok with
requiring these to be on the CAS Api only, but
also wouldn't object if they were on the CasView API for convenience.
The CAS has a getLowLevelCAS() method; the low level CAS includes both
things for FSs and also for IndexRepositories.
The index repository things should be looked at carefully to see if they
should go with the "view" (with perhaps "convenience" functions working
on the current view in the CAS Api).
Finally :-) we have getSofaIterator... on the CAS Api (I'm not
distinguishing between CAS and CommonCas APIs here).
I suggest for 2.1 we "lock" the association between 1 view <==> 1 sofa.
So we won't need getViewIterator, nor have to
figure out how to "name" views separately from Sofas. Is that too
restrictive?
-Marshall
