Jeremias Maerki wrote: > > 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 can't answer that because I have the impression that your proposal is > incomplete. What I'm missing: > - How to specify output properties like encryption parameters > - How to handle Java2D? > - How to handle SAX input? > - How to handle FOP configuration?
My proposal was not contemplating any significant changes to any of these. Encryption parameters would be stored/set in the FOPResult object (I've adopted your terms here even though the concepts might be a bit off -- I don't know whether that is more or less confusing). Java2D would be a FOPResult option, which would drive the creation of a RenderContext object to handle the AreaTree creation for that scheme. SAX input would be handled as it is now. FOP configuration would be handled as it is now, except for the changes to the object model. Perhaps I am not catching the intent of your questions? > > This implies (and makes sense when you > > think about interfaces) that it is a lowest-common-denominator. > > Yes, but holding that open for extensions: > - Ability to add new subclasses of FOPResult which only certain > implementations support. > - Ability to pass in special output property objects to control special > features. OK. One that is on the top of my mind is pluggable layout aka LayoutStrategy. Please walk me briefly through how that might work at the API level, considering that other implementations might not want/need such a thing, and how to handle defaults. What I am really grappling with here is whether you build such a concept into a shared, industry-wide API, or treat it as an extension, and if it is an extension, what the ramifications are, especially to those using the API. Specifically, if the outer shell of the API doesn't handle the extension, don't you end up kind of building (via subclassing or whatever) a separate API underneath the outer shell that is FOP-specific? (BTW, the above paragraph is not asking anyone to endorse the idea of pluggable layout, but simply using the concept as a specific example of the type of thing that we might want to have the flexibility to handle). > > 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. > > You're right again. But then it happens that a good API gets adopted by > other parties. At any rate I'll gladly participate in formulating a > standard API as a separate project as my time allows it. If there are any changes to the one that we propose, then we *must* change our API in order to meet it (one of the things we have specifically said we don't want to do), or not be compliant. And I don't think we want to wait for such a process anyway. > RenderX guys: If you're listening in, I'd like to hear your thoughts > about having/creating a common client API for XSL-FO processing in Java. BTW, we'd better change the name of FOPResult if we're going to try to sell this to a wider audience :-) > The biggest difference probably arises from your focus on the inner glue > and my focus on the client API. Your thoughts are very valuable but they > should evolve in the context of the inner glue because that's where you > invested most of your brain time, I guess. That's fair. I see the API as a function of the object model, and think the best way to assure a stable API is to get the object model to better match our processing needs. To the extent that the layer of API objects that you have designed meets that end, I think we'll be OK. If you and Joerg are satisfied that there are no major gotchas lurking, I am quite happy to follow along. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
