On 1/6/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
As I see it, we're not going to reach consensus on this issue. I guess this is at least in part due to the fact that we disagree on the basic premises underlying this redesign. I am -1 to the current proposal, and I'll give my reasons below. However, I think we've mostly discussed most of what I have to say, and if everybody else thinks the current proposal is a good idea, I will not stand in its way.
Yes, we have no consensus... And I don't think it's just you, Thilo. Marshall is still proposing changes and asking questions, and Eddie and Michael haven't had enough bandwith to devote much time to understanding and considering all the implications. And I must admit, I myself am having second thoughts about the problems with getting JCas to work, and about all the deprecation warnings we'd be causing in users' code. I suppose then we ought not to rush these changes in. I still think we missed an opportunity here, but it's not going to help anybody to rush in some changes that haven't been fully thought out. You're probably right that single-Sofa users will be happier if we *don't* do this change, and multi-sofa users are I think still a relatively small population and it may not be worth doing such a risky change to try to make them happier. They are generally sophisticated enough to adapt to whatever confusing API we present to them anyway. :)
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.
I think we're as far apart as ever on this point. In fact I'm so concerned with backward compatibility for Sofa-unaware annotators that I started to have cold feet about even *deprecating* the methods they use! Ironically, our diametrically opposed positions lead us to both question the current proposal... however, it does not bode well for agreeing on doing anything in UIMA 3.0 either. :(
The CommonCas interface adds to the confusion, because it isn't (a common CAS API). It follows the methodology that everything that can be abstracted, is abstracted. However, that's not how people think. We like to think in API groups and what things logically belong together, not what can and can not be grouped because of method return types. So all it does is add to the confusion because you always have to look in two places for APIs.
I think I agree with this... but see the other thread.
So here's what I would do: - 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. - Support both UIMA 2 and 3 in parallel, for as long as necessary. Consider interoperability, possibly in the same JVM.
I think interoperability in the same JVM is a requirement. Maybe before doing a clean slate design we ought to have a strategy for interoperability. I don't really see how we do this other than keeping the current CAS interface and adding a completely new one that's named something different (but what?). Or does anyone have a better idea how to accomplish interoperability? As for the actual clean slate design, I think maybe we ought to give the OASIS TC a few months to see what transpires, and try to figure out how this whole "implementation should conform to the specification" thing is supposed to work. In the mean time there should be plenty of work in getting UIMA 2.1 out and trying to cultivate a user community and attract some developers. Having a user community may also help in any future redesign. Thilo keeps saying he wants to hear the users' complaints/suggestions for himself on uima-user, rather than filtered through our personal interactions with the users. That's a good idea, but it will take some community-building work to get there. -Adam
