Adam Lally wrote:
From an interface point of view, does it matter? As I understand it,
you can neither create nor access FSs in the CasContainer (I'm just
calling it that to avoid confusion, not because I think that's a good
name). Or can you? What is the division of labor here?
What I intended to propose was that the "CasContainer" as you call it
would basically have all of the CAS APIs except getIndexRepository()
and the ones related to Sofas (including getDocumentText()).
What about addFsToIndexes()? I would assume that should live where
getIndexRepository() lives.
Essentially, this is what we already have implemented... except that
instead of not defining the methods on the CasConsumer (the "Base
CAS"), they are there but throw exceptions if you call them.
It would be nice to change that so they're not actually there (I think
that's what you're suggesting).
Let me see if I understand the proposal that's on the table. There is a
core set of APIs that both the view and the container will have, such as
createFS() and that whole family of methods. Then there's a bunch of
sofa-related stuff and getIndexRepository() which is only defined on
views. Finally, there's some view management stuff (such as
createView()) that will only be defined on the container.
Please let me know if I've misunderstood.
--Thilo
