FOP API proposal in FOP wiki

["J.Pietschmann" <j3...@yahoo.de>]

Hi all,
I polished the FOP API proposal at
  http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
a bit. Everybody is invited to review and add content. The discussion
points are after the code near the end.

I think real discussion, with arguments and counterarguments, should
take place on the mailing list, and the Wiki should be used as a
whiteboard holding the facts and thoughts worth to remember.
If a discussion point from the wiki seems to be somewhat resolved on
the mailing list discussion, reformulate it and the associated
comments into appropriate sections, like code, DTD, renderer config
or rationales, then delete it and all associated comments rather
than keep it indefinitely in the wiki.

Please bolster arguments for adding stuff with appropriate use
cases, perhaps adding to the usage examples section.

I hope Keiron, Karen and Arved will surface for this discussion.
I'll also post an announcement on cocoon-dev.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FOP API proposal in FOP wiki

[Jeremias Maerki <de...@greenmail.ch>]

I've just decided not to comment any detail point that has been
discussed ATM because I'm currently uneasy with the current process of
forming the new API. It's too much of a bottom-up approach IMO. I fear
that we're losing ourselves in some details when not even the high-level
stuff is decided.

I want to take it top-down:
1. top-level requirements (done, or does anyone have any additions?)
2. decide what kinds of APIs we're going to build. Only an Avalon-based
   one as the current Wiki suggests? Or an Avalon-based API targeted at
   the advanced user and a easy-to-use non-Avalon API as I suggested
   half a year ago? Shall we use Morphos as our Easy-API? Just questions
   that I'd like to have resolved before diving into details.
3. work out a detailed list of topics that need to be addressed (for
   example: different output formats: OutputStream, SAX events, AWT
   Graphics2D calls etc.)
4. Build up the API again based on the findings in 3 with the simple and
   essential things first (no image and font "resolvers" and similar),
   maybe even coding that part already to see if it might work. We can
   always change later. Let's stick to the fact that FOP is just a
   transformer/converter/morpher from a high-level view. Input in,
   output out. That's what the API should primarily be about. Things
   like resolvers are different concerns and have to do with the
   environment/configuration. This is to be separated IMO.

Flame me...

If not, please share your thoughts on point 2 now.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FOP API proposal in FOP wiki

[Nicola Ken Barozzi <ni...@apache.org>]

J.Pietschmann wrote:
> Hi all,
> I polished the FOP API proposal at
>  http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
> a bit. Everybody is invited to review and add content. The discussion
> points are after the code near the end.

Took just a quick look. The "Component" interface is deprecated. We used 
"Composable" that returned a Component, but it was not really needed and 
only a problem with using things that could not have that marked 
interface applied.

Now it's Serviceable, and it returns an Object.

I'll look at it in more detail later.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FOP API proposal in FOP wiki

["J.Pietschmann" <j3...@yahoo.de>]

Jeremias Maerki wrote:
> I just don't want to stand on your toes.

If I were afraid of someone stepping on my toes, I'd either
shut up or commit the stuff right to CVS and damn the flak!

The wiki is a whiteboard for collecting ideas. This includes
wiping stuff which did not stand the test of time. After all,
you can easily restore it if necessary.
The mailing list is for dialogues and argumentation.
I admit it takes some time to get used to this.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FOP API proposal in FOP wiki

[Jeremias Maerki <de...@greenmail.ch>]

On 17.02.2003 21:08:20 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > That was my original idea, to build FOP on Avalon, provide an
> > Avalon-based API (for advanced users and Cocoon) but have a standard
> > easy-to-use API that's not Avalon-based. Unfortunately, the Wiki page
> > currently doesn't reflect this.
> 
> No problem here: edit the proposal to reflect your views.
> It's a wiki!

I'll get to that. I just don't want to stand on your toes. You've got
your view, I've got mine. I want to get a solution that all of us are
happy with.

> > Avalon has a lot of benefits for us
> 
> This is exactly the problem with Avalon: it benefits the
> developers. But does it benefit the *users* in a tangible manner
> (other than getting the software earlier)? Exposing an Avalon-only
> API *will* get us flames.

I know. That's exactly the reason for the "Easy API".

> Users don't want to step up another
> learning curve. Particularly if the accumulated knowledge can't
> be reused elsewhere. How many public projects are there beside
> Cocoon which draw heavily from Avalon? I get 5 in the first 100
> matches of a Google search (one of them, ironically, on savannah).

Yes, yes, heard that argument many times now.

> BTW type "avalon" and "framework" into Google for a surprise.

Already knew that one. 


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FOP API proposal in FOP wiki

["J.Pietschmann" <j3...@yahoo.de>]

Jeremias Maerki wrote:
> That was my original idea, to build FOP on Avalon, provide an
> Avalon-based API (for advanced users and Cocoon) but have a standard
> easy-to-use API that's not Avalon-based. Unfortunately, the Wiki page
> currently doesn't reflect this.

No problem here: edit the proposal to reflect your views.
It's a wiki!

> Avalon has a lot of benefits for us

This is exactly the problem with Avalon: it benefits the
developers. But does it benefit the *users* in a tangible manner
(other than getting the software earlier)? Exposing an Avalon-only
API *will* get us flames. Users don't want to step up another
learning curve. Particularly if the accumulated knowledge can't
be reused elsewhere. How many public projects are there beside
Cocoon which draw heavily from Avalon? I get 5 in the first 100
matches of a Google search (one of them, ironically, on savannah).
BTW type "avalon" and "framework" into Google for a surprise.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: FOP API proposal in FOP wiki

[Jeremias Maerki <de...@greenmail.ch>]

On 05.02.2003 10:32:11 Klaas_Bals wrote:
> 
> Let me first quickly introduce myself. The compay I work for, Inventive
> Designers, has a product called Scriptura, which is tool to work with XSLT
> and XSL-FO. Scriptura consists of a WYSIWYG designer for XSL stylesheets,
> and an Engine which does the processing (transformations, PDF generation
> etc). It is written in Java. For more info, see
> http://www.inventivedesigners.com/products/scriptura.html
> 
> We are using FOP right now, but a lot of customers are asking for suppor
> tfor other XSL-FO formatters, which we encourage. However, right now we
> have to make a module for each of these XSL-FO formatters to access them
> using their proper APIs.
> 
> We see the need for a uniform (Java?) API to access all (Java?) XSL-FO
> formatters, which ideally would become a part of the JAXP (Java APIs for
> XML processing).
> My opnion is that the Avalonized API does not qualify for a uniform API,
> because of too much of the Avalon components would have to become a part of
> this uniform API in order for it to be complete.
> Do you guys see this Avalonized API as the one an only and best way to
> access FOP, or are you interested in having a uniform API as well?
> 
> Do you see this uniform API sitting on top of the Avalonized API?

That was my original idea, to build FOP on Avalon, provide an
Avalon-based API (for advanced users and Cocoon) but have a standard
easy-to-use API that's not Avalon-based. Unfortunately, the Wiki page
currently doesn't reflect this.

Have a look at the Morphos proposal in Jakarta Commons Sandbox. It's a
general-purpose transformation API. This could be a good start for a
uniform API.

> I must admit that I did not completely follow the discussion about the FOP
> API, altough I browsed the archives. I couldn't find the final conclusion
> on the decision to use the Avalon approach.

That's probably the concept of lazy concensus. Granted, Avalon has crept
into FOP over time. It has started with logging. But I'm pretty sure that
if we voted for Avalon today the majority of the committers would vote
+1. Avalon has a lot of benefits for us (which I'm sure you've already
come accross in the mailing list archives) and the Cocoon people (our
biggest customer) will love us for neatly integrating FOP with them,
because the current FOP is a PITA in such an environment.



Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org