On 17.06.2003 17:10:19 Victor Mote wrote:
> Jeremias Maerki wrote:
> > I'm a bit concerned that you call this "startup refactoring" where it's
> > really API redesign in the end, I think. And that's an important topic
> > where I would have expected you to ask for a "go for it" before starting
> > on this. Generally, JustDoIt (tm) is a good thing but this is about the
> > API and I'd like use to reach consensus on the direction. From the Wiki
> > page I read that there are substantial differences in our (you, Jörg, me)
> > ideas.
> I certainly thought I had tacit consent.

Well, I'm certainly guilty of letting trail off that discussion. I'm
sorry if I missed anything.

> > I'm a bit unhappy that you placed/left Session in the apps package. I
> > would like to see the apps package deprecated as a whole over time. I
> > would like a cli package that only contains the stuff needed for the
> > command line and I'd like to have (wish, not a demand) the main FOP api
> > in the org.apache.fop package.
> My humble apologies. What is the easiest way to roll it back? Is there an
> automated way?

I wasn't vetoing your changes, merely pointing out possible differences.
You didn't need to revert. But do you agree with what I wrote?


> OK. In my terminology, Session is a long-lived object that lives, well, for
> the Session. Document are children of Session. The only part of Session that
> you have seen is a renaming of Driver to Session. That is all that has been
> committed so far. But eventually nearly all of existing Driver gets pushed
> down to Document, RenderContext, and RenderTask. The only thing that really
> still lives in Session is the logging stuff, and it might belong with
> Document (under my scheme).

That's not what I'm talking about. Do we all agree on this terminology? Can
we find better classnames for what they are? These are key elements in
FOP's architecture. I'd like to have good names for them so they are
easily understandable even by outsiders. If you use Session you'll get
all sorts of strange questions. I'm pretty sure about that.


> Yes, I am talking about GoF Singleton. I understand the reluctance to use
> static variables, but I haven't adopted the no-tolerance approach that you
> have. The alternative is to either carry the static information around with
> you in every method that might need it, or to actually store the information
> in every object that might need it. I already see that with the logging. If
> it is needed, then OK, but I don't see it yet.

So I guess it's a matter of community decision what is preferred. Going
for statics and singleton is certainly easier but it'll carry you away
from the Avalon style of life. I have no problem if the majority of
committers think that Avalon should be thrown out. I didn't manage to
introduce the Avalon-patterns, yet, and it looks like I'm the only one
really pushing it so far but without enough power.

Jeremias Maerki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to