On 30.10.2003 01:50:49 Glen Mazza wrote: <snip/> > My current inclination after reading Victor and your > posts: > > 1.) (Still), move org.apache.fop.pdf to > org.apache.fop.render.pdf.pdfdoc (rename it similar to > our rtfdoc package). Get it cleaned up and perfected, > etc., remove obsolete classes, etc. *Then* discuss > its future componentization.
Fine with that. I think we're in a good position where we can freely move code within FOP without causing too much grief for others. Can we call it pdflib and rtflib instead of pdfdoc/rtfdoc? So, +0 from me. > 2.) Move org.apache.fop.rtf.renderer to > org.apache.fop.render.rtf. It doesn't matter that the > RTF renderer doesn't need an area tree, or descend > from our AbstractRenderer.java, etc., etc.--actually, > that may be something to celebrate. For the solid > foundation that Victor was talking about, the > renderers should be placed together in the same > package--sooner or later they're probably all going to > be implementing a common (very) high-level interface > anyway. > > [Are you in sufficient agreement on this one, > Victor...if you can take of this with Peter's latest > patch, that would be great...] +0, too. > 3.) Move the rest of the rtf packages under > org.apache.fop.render.rtf. No more rtf in FOP's root. > (This issue is more controversial than #2 above, and > can wait.) I don't see why this is more controversial than #2. It's practically the same as #2. +0 > 4.) MIF hold off on until we know what to do with it. Hmm, there is no MIF renderer at all, ATM. Following your points above you'd have to dump the code in ...fop.render.mif.miflib until someone writes another MIF renderer. > For code reuse: > > 5.) While FOP can happily use lots of components (svg, > avalon, etc., the more the merrier) it should not be a > repository itself for components. Like Batik and > Xalan, all packages and classes in FOP should be put > into places that make architecturally the most sense > in FOP itself--as if no one else is using the code. > More to the point, we don't keep dumping things in the > root out of concern that an app importing us will need > to use a long import statement to get to our classes. > > Example: our svg.PDFTextPainter imports from > "org.apache.batik.gvt.text.TextPaintInfo". When > creating this class, Thomas DeWeese (?) did *not* say > "Uh oh...it would be horrible for FOP's code to be > ruined with such a long import statement...I'm going > to break Batik's architecture and place > TextPainterInfo in Batik's root just so FOP can have a > shorter import statement. It is more important to me > that FOP looks better, even if I have to turn Batik's > design into architectural sludge." > > I think the error in thinking here was that external > users--at least the good ones--would *want* our > classes to be anywhere other than the best place for > FOP itself anyway! Open-source users want SW to be > highly used, highly successful--personally, I'll > happily write Texas-sized import statements so long as > it keeps Batik the most solid SVG product. I don't get your point. What's the problem with long import statements? > 6.) After a component is cleaned up and gets demand > from someone externally, move it to XML-Commons. > Then, have FOP reimport the new XML-Commons package. If you ask me most components that could be factored out from FOP are slightly out of focus for XML Commons. The PDF library for example has little to do with XML. I'd personally put it in http://commons.apache.org. But all that is debatable and some people will see it differently. I'd really start by separating the components but keeping them within the xml-fop module (not immediately, only when someone itches enough. I'm starting to). From there they can easily be moved elsewhere if desired but the obligation to create a clean design is already given. Another benefit is the ability to clearly state for every component in what state (proof-of-concept, beta, productive) it is. Less questions like "it works in PDF but doesn't in PCL". Is that an option for you? > 7.) Keep going. Keep cleaning up and keep moving to > XML-Commons, and keep re-importing into FOP. But > nothing get moved to XML-Commons unless there is a > legitimate demand for it first. (Don't want to send > them 14 things, only 6 of which end up getting used.) But a component may only get recognized as such when it has its separate place. As I said before I'd be careful what to separate from FOP. Only things that have promise to be used in more than one project. If SVG code is moving over to Batik the above is true for PDF and fonts code. > This one is going to take Victor the most amount of > self-discipline--I'm not very optimistic here--he'd > send his son to XML-Commons if he could get away with > it! ;-) IMO this is unfair despite the smiley. Jeremias Maerki
