Jeremias Maerki wrote: > > > 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?
Reversion is already completed -- if other changes start getting checked in, then it becomes a much more difficult task. WRT to the location of the "Session" concept, I don't have strong feelings about it the way some others do, and I viewed that as an issue that could be resolved later by simply moving it wherever you guys decided it should go. > > 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. I am not committed to the name "Session", but can't think of a better name, even with the help of my trusty thesaurus. I think FrameMaker uses that name in its FDK API. Microsoft uses "Application" for the equivalent concept in its Office 2000 object model. I didn't like "Driver" much or I would have left it alone (that implies a different concept to me). I suppose FOPInstance, or RuntimeInstance might work. I didn't realize that there would be misunderstandings of "Session". > > 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. I'm not opposed to Avalon, but I might be if I understood it. It probably seems lazy that I am not up to speed on it yet -- I have tried a couple of times to get the big picture from the doc, but concluded that I won't get my arms around it until I use it (IOW, the doc wasn't very helpful). If the static construct and Avalan are mutually exclusive, the former seems far less invasive, and easier both to implement and un-implement. However, I realize that there are more things that you want to do with Avalon that might require that invasiveness anyway. Sorry I am not more help here. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
