Hi all, The main issue for me in this situation is not the actual change of interface but the problem of the getWidth (and some others) method which is no longer implemented.
Ideally I want to change to batik1.1 when it is available and update the interface at the same time. Updating the interface is most likely (I hope) a simple task. In this case I don't think there is any need for a backward compatible interface. The thing that I really want is the getWidth method to be useable when batik1.1 is released. This is a runtime compatibility issue that I was aware of soon after the change, I just haven't got around to raising the issue, preoccupied with some other areas. I suppose it could be useful for this sort of problem to also be made publicly known in a similar way that the interface changes are known. As a side note: It would be good if the TextPainter system was easily extended so that for simple text that can be represented in pdf we put the text directly into the pdf and for more complicated text (effects, overline, underline etc.) the stroking text painter could handle it. Rather than the current situation where the stroking text painter can handle everything but makes large pdf files, the pdf text painter only handles simple text. On Tue, 18 Sep 2001 16:36:11 Vincent Hardy wrote: > Sam, > > Sam Ruby wrote: > > > > ... > > > > Just to clarify - FOP may or not be building off of the xml-batik CVS > > repository, but I do. The reason why I do is exactly to provide early > > warning of such impending changes in order to promote discussion. > > Understood, and thanks for doing what you do: it is helping us right > now! > > > > > > What is happening is that we are fixing what we think was a design > > > error and we are removing a parameter from a large number of methods > > > in GVT, one of the core Batik modules. You are right, we are not > > > deprecating the old signature, even though I agree deprecation is > > > good practice. > > > > You are also adding a parameter to a fair number of methods. Note that > in > > this case, we are discussing an interface, so it is not clear that > > deprecation of methods is an effective means of providing backwards > > compatibility. Any additions or changes will require source code > changes > > to implementors of this interface. > > Yes, you are right. So I think we agree deprecation is not a good > solution in our case. > > > > > ..... > > > > One thing that works in some occasions is to rename the interface, and > for > > a period of time support both the old and new interface. > > > > This would be very difficult here. There is not only one interface > or class which changed but a fairly large number. Therefore, the > dual support (old/new) did not seem like a viable option to us > and especially to Thierry who made this difficult, widespread > change. > > > > Here is what I suggest: > > > > > > a. Short term, build using the batik 1.1rc2 release. > > > b. Wait until Thomas completes the wide-spread changes Thierry has > > > started (this will further impact the TextPainter interface). > > > c. Once the API is stable again, update your TextPainter > implementation > > > so that it no longer uses GraphicsNodeRenderContext. > > > d. Then, you can either use the Batik CVS again or use our next > > > developer release. > > > > The thing to consider here is that often batik and fop are often used > in > > combinations with other components. An example I mentioned in my > previous > > e-mail was cocoon. Even after the next release of batik, cocoon may > need > > to hold back support for this new release lest it steps up to a release > > that fop does not support. And even cocoon is a component that others > may > > choose to build upon. > > > > In general, it is not possible to coordinate the upgrade of every user > of > > an open source project. > > > > The overall strategy which I recommend is that every time a breaking > change > > is required, try to have at least one public release in which both the > old > > and new interfaces are supported, with the old interfaces deprecated. > > I understand your arguments and I agree with them, but > I would also point out that implementing both the old and new interface > can be a costly proposal in terms of development effort. > > So, I think that we should consider implementing the old/new interfaces > in regards to the cost/benefit ratio. For example, depending on > how public is the API change, we may decide to have the intermediate > step or not. What I mean by 'how public' here is that a change > to the internal interfaces/classes of a module (like in our case) is a > lot less likely to cause problems than a change to the very > top level APIs (SVGGraphics2D would be a good example in Batik). > Therefore, > the amount of efforts required may or may not be justified. > > Of course, the FOP extension of TextPainter shows that we have a user > where we thought we had none, but the cost of implementing both > the old and new interfaces would have been pretty high... > > In summary, I think we are in an unfortunate case that, thanks to your > efforts, was spotted early. Your point about having an intermediate > step with old/new interfaces is well taken, even though > I think it does not apply to the specific situation we are discussing > (given the cheer volume of changes in our GVT module). > It will, however, apply to many changes we will face in the future. > > Thanks, > Vincent Hardy. > > > > - Sam Ruby --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
