Sorry for the delay. On 16.07.2004 19:00:25 Victor Mote wrote: > Jeremias Maerki wrote: > > > Making these parts into separate components is in line with > > what I have in mind when can talk about a shared repository > > between Batik and FOP. I hope I can take a good look into > > Good. I think it has potential to be useful to many applications. > > > what you did later. From a quick look, however, I wasn't very > > pleased that you propose to use a lot of statics in the > > "FontServer". I would prefer to have the possibility to > > define multiple configurations in a heavy server environment > > without having to go through the pains to separate multiple > > environments using classloader magic. The system fonts are ok > > like this, of course, but not the user-defined. Just my opinion. > > I knew this would be controversial, and I'll be glad to consider changes. > The use case that you mentioned will, I think, be handled by some of the > other planned changes to configuration that are in the works. These changes > will be more client-centered than server-centered. So, rather than having > multiple servers configured different ways, each client will tell the server > more about what it wants, and the server will react based on this. However, > I may not see all of what you are thinking about here. If you can be more > specific, I'll think through this some more.
I'm simply thinking that adding statics is a lot easier than removing them again. I usually create non-static classes and create singletons around them if necessary or convenient. That's basically it. > One of the main purposes of > FontServer was to share as much of the Font overhead as possible between > documents in a heavy server environment, while keeping a light footprint in > the code. I actually tried to write it in a non-static way (with you in > mind) in the beginning, but it just ended up being silly, at least for the > purposes that it is currently designed for. Of course, it makes sense to take the easy way to get quick results. I'm just thinking about the long run. > > Concerning the PDF library, I suggest you start from the PDF > > lib in CVS HEAD instead of using the maintenance branch, even > > if it means that the API may be a bit different. I've > > invested a considerable amount of time to make the whole > > thing better. Things such as encryption are much more cleanly solved. > > First, in relation to FOP 0.20.5 (approximately FOray's starting place), the > changes that you are talking about are improvements, and I don't want to be > introducing changes or improvements yet. The goal here is really to make > sure nothing is broken. Then we can start making improvements, releasing > them, and getting user feedback. Valid approach. I'm trying to find ways to bring everyone together in places where consensus may be possible. > Second, I *know* that, while in many ways HEAD is superior to the > maintenance branch, there are many specific instances where the maintenance > branch is superior to HEAD. I also know that there is no convenient list of > such items. I have to choose between the two evils of 1) losing benefit(s) > in the old code, and 2) losing benefit(s) in the new code. Of the two, I > prefer the latter. The user is not going to be happy if I remove his wheels > while installing the new, more powerful engine. Better IMO for us to upgrade > the engine in a manner that ensures that the wheels stay on. FOP is kind of > into the chasm thing, and FOray is definitely not. Right, but would you reconsider (in the long run) if we worked towards seperately released components that could be stabilized and shared between the different implementations? All in the spirit of avoiding duplicate effort where this is possible? > Third, what you suggest is much easier said than done. I have made a note to > specifically check the encryption stuff when I get a chance. I suppose that > we can either diff the code (probably only useful to those who wrote it) or > use "missing feature" hunt. IOW, if we get to the place where we are > releasing code again, then, when issues come up on fop-user, hopefully you > or someone else will say "I already fixed that in HEAD", Oh, I said that a number of times already. ;-) > and we can > reconcile them. Ideally we want to get to the place where both branches are > using the same code. I *think* that is pretty easy for Fonts and Graphics, > but, as you say, probably not as easy for PDF, and probably PostScript too. If it's possible for fonts then I'm sure it's possible for PDF and PS. Jeremias Maerki
