Avalon Awareness not worth it

[COFFMAN Steven <SC...@CBSINC.com>]

FOP is already treated as a black-box Avalon Component by Cocoon 2 (and the
broken Cocoon 1). Functionally, additional "Avalon-ness" doesn't get FOP
anything. The software engineering practices are great in theory, but
they're still evolving and poorly documented at this point, plus they'd
require a major FOP refactoring. Since FOP development has been "many minor
patches" rather than an individual spending 40 hours a week on it, I think
any such goal would just stall FOP out. Once Avalon is better documented and
stabilized, it'd be good to read it so things can gradually evolve in that
direction. Or if we get a full time FOP person.

The Avalon functionality goodies are only available to services/servers,
which FOP isn't. When FOP is used as part of one, such as Cocoon, then FOP
could use Avalon logging, configuration, etc., but you'd have to have
"if(fopComponentManager == null)" all over the place for CommandLine,
XTCommandLine, AWTviewer, etc.

The avalon folks are all jakarta/cocoon/james service/server folks, so
they're understandably uninterested in adding extra non-server code that
would make it more attractive to components that also run stand-alone. You
wouldn't believe how much everything is in flux over there too! They were
arguing over fundamentals until just recently.

-Steve
-----Original Message-----
From: Eric SCHAEFFER [mailto:eschaeffer@posterconseil.com]
Sent: Thursday, September 07, 2000 11:12 AM
To: fop-dev@xml.apache.org
Subject: Re: bugs


What do you suggest ?

(I'd like (but not have time) to make FOP Avalon aware, and it implies to
change a lot of classes...)

Eric.


----- Original Message -----
From: "Christer Morén" <ch...@omgroup.com>
To: <fo...@xml.apache.org>
Sent: Thursday, September 07, 2000 4:51 PM
Subject: bugs


>
>
> 1) Someone else that could see whats wrong with the following piece of
code from
> MessageHandler.log (x), MessageHandler.error (x) has the same problem.
>
> case NONE:
>   // do nothing
> default:
>   System.out.println (message);
>
> 2) When a new LineArea is created in BlockArea.addText (x) it would be
nice if
> the pending areas from the preceding LineArea were kept, otherwise there
exist a
> possibility that some characters will be lost. The solution is easy:  Copy
the
> vector and int containing the pending area information from the old to the
new
> linearea,
>
> Another issue: Does it exist any plans on rewriting/restructure fop?? The
> biggest problem as I can see today is that fop consumes to much memory and
it is
> nearly impossible to produce large documents on an ordinary workstation.
>
> /c
>
>

Re: Avalon Awareness not worth it

[Eric SCHAEFFER <es...@posterconseil.com>]

----- Original Message -----
From: "COFFMAN Steven" <SC...@CBSINC.com>
To: <fo...@xml.apache.org>
Sent: Thursday, September 07, 2000 6:44 PM
Subject: Avalon Awareness not worth it


> FOP is already treated as a black-box Avalon Component by Cocoon 2 (and
the
> broken Cocoon 1). Functionally, additional "Avalon-ness" doesn't get FOP
> anything.

Why ? FOP needs a configuration file, and something to help removing static
classes/methods. Avalon can be used for this: a ComponentManager to obtain
components (remove static things) and a Configuration to configure FOP.

> The software engineering practices are great in theory, but
> they're still evolving and poorly documented at this point, plus they'd
> require a major FOP refactoring. Since FOP development has been "many
minor
> patches" rather than an individual spending 40 hours a week on it, I think
> any such goal would just stall FOP out. Once Avalon is better documented
and
> stabilized, it'd be good to read it so things can gradually evolve in that
> direction. Or if we get a full time FOP person.

Sure, it's not easy to understand Avalon, and to be up to date...

>
> The Avalon functionality goodies are only available to services/servers,
> which FOP isn't. When FOP is used as part of one, such as Cocoon, then FOP
> could use Avalon logging, configuration, etc., but you'd have to have
> "if(fopComponentManager == null)" all over the place for CommandLine,
> XTCommandLine, AWTviewer, etc.

The command line "wrappers" can create a ComponentManager and a
Configuration, no ?

>
> The avalon folks are all jakarta/cocoon/james service/server folks, so
> they're understandably uninterested in adding extra non-server code that
> would make it more attractive to components that also run stand-alone.

Cocoon also run stand-alone...
And isn't FOP a service, in a certain way ?
The only thing I see that could be modified in Avalon is their "parameter"
stuff (you can't represent all parameter types, like lists)

Maybe we could use or create something different (and simplier) to solve FOP
problems, but why don't use Avalon ?

> You
> wouldn't believe how much everything is in flux over there too! They were
> arguing over fundamentals until just recently.

Even on ComponentManager and Configuration ?

>
> -Steve

Eric.

> -----Original Message-----
> From: Eric SCHAEFFER [mailto:eschaeffer@posterconseil.com]
> Sent: Thursday, September 07, 2000 11:12 AM
> To: fop-dev@xml.apache.org
> Subject: Re: bugs
>
>
> What do you suggest ?
>
> (I'd like (but not have time) to make FOP Avalon aware, and it implies to
> change a lot of classes...)
>
> Eric.
>
>
> ----- Original Message -----
> From: "Christer Morén" <ch...@omgroup.com>
> To: <fo...@xml.apache.org>
> Sent: Thursday, September 07, 2000 4:51 PM
> Subject: bugs
>
>
> >
> >
> > 1) Someone else that could see whats wrong with the following piece of
> code from
> > MessageHandler.log (x), MessageHandler.error (x) has the same problem.
> >
> > case NONE:
> >   // do nothing
> > default:
> >   System.out.println (message);
> >
> > 2) When a new LineArea is created in BlockArea.addText (x) it would be
> nice if
> > the pending areas from the preceding LineArea were kept, otherwise there
> exist a
> > possibility that some characters will be lost. The solution is easy:
Copy
> the
> > vector and int containing the pending area information from the old to
the
> new
> > linearea,
> >
> > Another issue: Does it exist any plans on rewriting/restructure fop??
The
> > biggest problem as I can see today is that fop consumes to much memory
and
> it is
> > nearly impossible to produce large documents on an ordinary workstation.
> >
> > /c
> >
> >
>

Re: Avalon Awareness not worth it

[Berin Loritsch <bl...@infoplanning.com>]

COFFMAN Steven wrote:
> 
> FOP is already treated as a black-box Avalon Component by Cocoon 2 (and the
> broken Cocoon 1). Functionally, additional "Avalon-ness" doesn't get FOP
> anything. The software engineering practices are great in theory, but
> they're still evolving and poorly documented at this point, plus they'd
> require a major FOP refactoring. Since FOP development has been "many minor
> patches" rather than an individual spending 40 hours a week on it, I think
> any such goal would just stall FOP out. Once Avalon is better documented and
> stabilized, it'd be good to read it so things can gradually evolve in that
> direction. Or if we get a full time FOP person.

A pitty, but I definitely understand.  Bear with us please.

> The Avalon functionality goodies are only available to services/servers,
> which FOP isn't. When FOP is used as part of one, such as Cocoon, then FOP
> could use Avalon logging, configuration, etc., but you'd have to have
> "if(fopComponentManager == null)" all over the place for CommandLine,
> XTCommandLine, AWTviewer, etc.

We are aiming toward an interim release soon, and in that release the
logger should be a system level component (i.e. available to everyone).
I beleive the Thread Manager is moving in that direction as well.  In the
following release there will be a configuration engine that (should you
need it) you would be able to use.

As to the if (fopComponentManager==null) comment, that is not true.  It
is covered by contract that all Composers are given a useable ComponentManager.
Again, better documentation would help.  I will be working on that once
the release is ready.

> The avalon folks are all jakarta/cocoon/james service/server folks, so
> they're understandably uninterested in adding extra non-server code that
> would make it more attractive to components that also run stand-alone. You
> wouldn't believe how much everything is in flux over there too! They were
> arguing over fundamentals until just recently.

The remodeling is almost over.  We will have a split development tree:
one for proposals and new work, and the other for the released version.
We here your cries and are working on making a stable foundation to work
from.  It is true that our first concern is to service/server applications,
but if there are some general purpose Components you need don't hesitate
to ask.  We have limited resources, but we want to make a very compelling
platform.

I hope you don't abandon us altogether, after the next two releases we
should have a stable platform to center development around.  I hope you
continue with your plan for modularly migrating to Avalon Awareness,
but trust me when I say the revolutionary approach definitely isn't
worth the effort just yet.

We have come to consensus about a number of things so it isn't as hostile
as you make it out to be.

Re: instream-foreign-object

[Keiron Liddle <ke...@aftexsw.com>]

Rikard,

Currently the instream-foreign-object is a block area, not an inline
area.
Obviously this will need to be fixed, I will look into it sometime.

Sorry it won't be fixed in time (probably already too late).

Keiron


Rikard Herlitz wrote:

> is there a way of making an instream-foreign-object inline?
> I need to draw svg-pics inline...
>
> thanks!
> /Rikard

instream-foreign-object

[Rikard Herlitz <Ri...@excosoft.se>]

is there a way of making an instream-foreign-object inline?
I need to draw svg-pics inline...

thanks!
/Rikard