ready to go again

[Victor Mote <vi...@outfitr.com>]

OK, I am ready to jump in & do some work. Sorry for being out of action for
so long. The threads that I would like to complete, or at least resolve,
first, are:

1. Documentation. The main problem here is the web site generation, but it
seemed to me that Peter and some others may have gotten that working. If so,
is the readme doc up-to-date? (The last time I tried to run it, in December,
the generation failed with errors).

2. Fonts. Jeremias & had some brief design conversations a few weeks ago. He
argued for an interface, I argued for a concrete facade implementation. He
is probably getting his doctrine from the "Design Patterns" book, and he is
probably correct. Another principle taught in that book is that inheritance
tends to be overrused, and that is specifically what I am trying to prevent
with my approach. In my mind, there is tension between encapsulation and
inheritance. So, if we can hide all of the implementation details behind the
interface just as well as we can behind a facade, so that layout doesn't
know or care what kind of font it is dealing with, then we are OK. Ideally,
we want to do the same thing for the renderers, if possible.

Victor Mote (mailto:vic@outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650
Fax   +1 (720) 293-0044


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

RE: ready to go again

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

> don't want another lengthy discussion started with my comments above. It
> may even be best if you did it your way for now (we need to get the ball
> rolling) and we adjusted the code to the Avalon environment as soon as I
> have set it up. I'm still trying to get my mind focused on that task

Actually, I was trying to concede to your approach. Your point about getting
started is well taken, so I will. I am still not up to speed on Avalon, but
will try to keep after that in parallel with this work.

> By the way: Do we have to vote for the full adoption of Avalon in FOP? I
> still sense some resistance on this topic.

I am still too ignorant on the topic to have an opinion. Joerg's comments
about an extra burden on the users worried me, and made me think that I have
misunderstood the whole concept of what Avalon should be doing for us.

Victor Mote


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

Re: ready to go again

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

On 18.02.2003 18:38:43 Victor Mote wrote:
> OK, I am ready to jump in & do some work. Sorry for being out of action for
> so long.

Hey, no apology required.

> The threads that I would like to complete, or at least resolve,
> first, are:
> 
> 1. Documentation. The main problem here is the web site generation, but it
> seemed to me that Peter and some others may have gotten that working. If so,
> is the readme doc up-to-date? (The last time I tried to run it, in December,
> the generation failed with errors).
> 
> 2. Fonts. Jeremias & had some brief design conversations a few weeks ago. He
> argued for an interface, I argued for a concrete facade implementation. He
> is probably getting his doctrine from the "Design Patterns" book, and he is
> probably correct.

Partially. More from experience working with Avalon for the more than 2
years.

> Another principle taught in that book is that inheritance
> tends to be overrused, and that is specifically what I am trying to prevent
> with my approach. In my mind, there is tension between encapsulation and
> inheritance. So, if we can hide all of the implementation details behind the
> interface just as well as we can behind a facade, so that layout doesn't
> know or care what kind of font it is dealing with, then we are OK. Ideally,
> we want to do the same thing for the renderers, if possible.

This is getting academic. (no offense intended, I'm just not used to
talk about this on an overly theoretic level)

Let me put it that way: An interface establishes a clear contract
between to subsystems. An implementation of the interface might be a
direct implementation of some functionality or an adapter to some
existing functionality. The user of the interface doesn't (and shouldn't) 
care about implementation details. This is different when you base your
work on an abstract base class for example. Things like logging or
lifecycle management influence this class and all its decendants
directly. That may mix concerns (see Avalon: Separation of Concerns). I
hope this makes sense. What I'm going for is this: I'd like to be
prepared when it comes to looking up services from an Avalon container.
Avalon-based system lookup (work-) interfaces. All lifecycle is handled
by the container.

I don't want to dictate how you have to develop the font stuff and I
don't want another lengthy discussion started with my comments above. It
may even be best if you did it your way for now (we need to get the ball
rolling) and we adjusted the code to the Avalon environment as soon as I
have set it up. I'm still trying to get my mind focused on that task
(difficult with all the licencing, PMC, support stuff going on). Anyway,
it high priority on my side and I'm still ready to help you on the font
stuff.

By the way: Do we have to vote for the full adoption of Avalon in FOP? I
still sense some resistance on this topic.

Jeremias Maerki


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