Jeremias Maerki wrote: > > That is not reuse. The metadata example is a trivial one. A > Collection of > > Fonts used and Fonts to be embedded would be a more important > one. However, > > I don't care. You are correct that we aren't talking about the > same thing. > > Then you mean reuse in the context of producing multiple output formats > in one renderung run?
Yes. Even if we think we don't want that now, we should have the flexibility to add it later. > > Hmmm. The whole thing seems pretty heavyweight to me (at least > compared to > > my proposal). Since my real interest is Control and not API, I think the > > most productive thing for me to do is to simply defer on the > API issues to > > those of you who care more about them. As long as we can build whatever > > Control infrastructure under that API that we want to (and it > looks like we > > can), and if you guys are happy with the API, we can defer that > part of the > > discussion until another day. It may very well be that when I > see how your > > vision is implemented, I will find the Control structures that > (I think) I > > need and that we are done anyway. > > I think we're getting in the right direction. I think, my API proposal > would enable a stable API and you can concentrate on what's necessary to > do inside FOP to handle the whole processing. You can even experiment > over time, changing the inner glue without changing the API. And a > stable and flexible API is one of the most important things to me. We > changed the Driver class too many times. Hopefully, my proposal could > improve this. Just trying to decouple... I suspect that the reason the Driver class had to change so often is that it was doing duty for three different hierarchical concepts by my count. As long as we have all three of them accounted for with your proposal, I'm OK with it (although see one afterthought see below). > But I disagree with the heavyweight thing. It's only the most necessary > things well separated by topic. Expand on your proposal to enable all > the functionality my proposal covers. I wonder how lightweight yours > stays. Except for Avalonization (which I admit I don't understand, but which I understood not to be a factor here), I don't see what functionality your model provides over mine. On the Avalonization issue, I guess the easy way to get to the heart of the matter is to simply ask whether Avalonization can be implemented with the model I have proposed or not. I did have one afterthought that I think I should mention. The JAXP thing caught me a bit off-guard, and I only just now sorted out in my mind why. I don't use these tools often enough or in enough detail to keep this fresh in my mind (but I think I have the concepts straight), so please correct me if I am wrong. If I want to use Xalan, for example, I could use a Xalan interface, or I could use a Xalan implementation of the JAXP interface. You mentioned in an earlier posting that the functionality between the two didn't necessarily need to match up. This implies (and makes sense when you think about interfaces) that it is a lowest-common-denominator. There may be times when, to get the full richness of an implementation, you have to use things that are specific to it because the higher-level interface couldn't and shouldn't force all implementations to implement that feature. FOP and RenderX might (and probably already have) evolve(d) to meet different use-cases. So it makes sense to me to use a simple lightweight API for FOP (if possible), and if we want to build an industry-standard API like that which you have proposed, that it be done in a separate project or at least package, and probably be done in concurrence with the other implementors. That would be my preference, but I do not feel strongly enough about it to do much more than mention it. I think this distinction probably also explains the different wavelengths that we seem to be on. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
