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()). 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.
You're probably right, but I'm not there yet. I'd like to get the concepts sorted out in my head before I get to implementation details like where the heap lives and how we do serialization.
I don't want to get into *how* we do serialization either, just what the user can see. And the fact that one CAS maps to one serialized document is important.
I don't know about that. I certainly wouldn't want to keep calling what I call the CasContainer the CAS. That may make sense from a 10.000ft view, but if you look at the API/interface level, there is very little the old CAS interface and the new CasContainer interface have in common. For somebody who hasn't been using views, a CasView is just like a CAS, while the CasContainer is a new animal. The fact that FSs can be cross-reference doesn't bother me. Do we keep all those FSs on a single heap, or do we have one for each view? That's an implementation detail that may change tomorrow, and it should not affect our users at all.
This may be 10,000-foot, but I think of the CAS as being what's passed between annotators as a basic UIMA concept that's worth preserving. -Adam
