On Sun, 21 Aug 2005 02:29 pm, Jeremias Maerki wrote:
> The "API discussion" thread around 2005-08-03 trailed off. I'd like
> to revive it again because I feel that is something that needs to be
> done.
>
> Anybody against moving the CLI to a org.apache.fop.cli package?

For command line applications I like it short and sweet, e.g. 
org.apache.fop.Fop would be fine with me. The current 
CommandLineOptions could go into org.apache.fop.cli.

>
> The only issue I see when doing this is that FOP's API then still
> resides in the org.apache.fop.apps package which is sort of
> unintuitive then. "apps" would suggest a command-line application IMO
> but we're then only talking about an API. In the end it comes back to
> the discussion about the API. Is the API ok like it is? Is it in the
> right package?

I agree, it is an unintuitive package name. I am not philosophically 
against having the command line application and the exposed API in the 
same package. But certainly not in the same class. What about moving 
the API part from the current org.apache.fop.apps.Fop into 
org.apache.fop.FOProcessor?

> We've already broken API compatibility so changing packages (I'm
> thinking think about org.apach.fop, removing "apps") shouldn't be a
> big deal before the first release.

As long as we don't do anything that prevents from creating a wrapper 
org.apache.fop.apps.Driver class for those who like backwards 
compatibility -:).

> Anybody against my adding support for selecting the renderer by the
> use of the MIME type (in addition to the current integer constants)
> and adding a renderer discovery (similar to FOP extensions and what I
> recently added for the XMLHandlerRegistry)?
>
> On the other side, maybe we should really take the time to write up a
> short specification for the API and to have that voted on. After all,
> this is the main entry point into FOP. If anybody could take the lead
> on this, I'd be very grateful as I have my hands full enough already.
> I can still do it myself, if really nobody can be found to do it. But
> I'd really not do all that stuff in a "lonely rider" fashion.

Only looking a structural aspect and not the details of the API we have 
options like:

a) Don't do anything leave it as it is as it avoids quite a bit of 
refactoring work and redoing all the examples, etc..

b) Move all command line stuff into org.apache.fop.cli including the 
application and move all API stuff into org.apache.fop.api.

c) Move the command line application to org.apache.fop, move anything 
required just to support the command line app to org.apache.fop.cli. 
Also move all API classes, i.e. all classes exposed to users wanting to 
embed FOP up one level to org.apache.fop. Make sure that the command 
line application is in a different class than the main API class, i.e. 
don't overload Fop.java.

d) Do some mix of b) and c), e.g. move command line app to 
org.apache.fop and move the API to org.apache.fop.api.

In all cases but a)  the org.apache.fop.apps package will disappear.

> Jeremias Maerki
Manuel

Reply via email to