Eddie Epstein wrote:
Thilo,
The switch from single-artifact CASes to multi-Sofa CASes and views was
a fundamental change in the basic UIMA architecture. We are not doing
our users a favor by hiding this change from them.
The main point of the new proposal is to make all annotator writers
aware of
multi-artifact capabilities, and this will be emphasized in the
documentation.
Maintaining the ability to run Sofa-unaware code without changes would only
be
bad if the resultant design suffered too much. [CAS.getIndexRepository()
discussed below]
... no separate view API, just a setCurrentSofa(Sofa) on the CAS.
... setView(String viewName)
We now have experience working with a number of multi-artifact
applications,
and
the most common practice is to be working with more than one view at the
same time.
Having a single CAS handle and changing which view it represents would
result
in a much less transparent code ["which view is the CAS pointing at now?"]
as well
as adding more lines of code [adding setView() calls].
Good point. So no setView(). The rest still hold ;-)
I question the need for backward compatibility for Sofa-unaware
annotators. Those days are over. This basic tenet robs us of the
ability to clean up the CAS APIs. For example, when I look at the CAS
APIs from a world where views are real, I naturally expect
CAS.getIndexRepository() to return all indexes in the CAS to me, not
just the ones for the default view.
So far there has been no use case for iterating over all annotations in all
views. If it turns out to be important, a new method signature on CAS could
be used to do so. Is this the only price we are paying for maintaining
backwards
compatibility?
It was advanced as an important spec compliance point by Adam. I don't
see it reflected in the current proposal.
Start discussing UIMA 3 now. Take a clean slate approach, consider
how we want to handle indexing in the future. Have a couple of beta
releases to get feedback from users.
Multi-Sofa code has been out and used extensively for the last 18 months.
The changes in the concrete proposal are based on that experience.
Then let the users speak. I don't know a single one. Maybe if I knew a
few, I would be less pig-headed. I know plenty of users who will not
thank us for making a complicated API even more complicated, without any
apparent benefit (to them, blessed view-free souls that they are).
--Thilo
