Re: FOray 0.1 release
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
RE: FOray 0.1 release
Jeremias Maerki wrote: 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. I didn't do it for the quick results, but for the lighter, cleaner effect in the client application. Consider the pro-forma FontServer static method someMethod(). Right now, using such a method is simply FontServer.someMethod(). If I convert FontServer to a singleton, I see only two choices: 1. Create a static method getInstance() to return the singleton. To use someMethod(), I now need: FontServer.getInstance().someMethod(). 2. Cache the FontServer instance somewhere in the application client and pass it around. To use someMethod(), I now need: someObject.getFontServer().someMethod(). The only reason I can think of to use a Singleton instead of statics is that I might want to change my mind later allow multiple instances. Since I have been unable to find even a potential use case for multiple instances that isn't covered by better client configuration, I didn't see the need for the extra complexity. However, I am not really opposed to using a singleton, and if it will make folks more comfortable, I'll reimplement it that way. BTW, I was under the impression that you disliked GoF singletons as much as statics. Are you OK with one here? 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? I understand you to be asking whether I want to create components that can be used by both the maintenance branch and HEAD. The answer is an emphatic YES. And I want all of the features that are in HEAD in those components. The only thing I meant to disagree with was the suggested approach of starting with HEAD as the baseline. IMO the correct approach is to start with the maintenance branch as the baseline and try to add in the code that has been added to HEAD as we are able to identify it and port it. Neither approach is ideal. If I understood the above correctly, then you and I may be in pretty close agreement on this whole approach. And, if you extend it a bit to other parts of FOP, you can see where I was headed with the isolation of FOTree, AreaTree, etc. It should be possible to factor everything out of FOP until you are left with layout, which could be / should be / would be the only difference between the maintenance branch and HEAD. Add in the concept of LayoutStrategy, and you have everything back in one unified line of development. 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. My perception is that *not* many features have been added to fonts and graphics in HEAD, but that many have been for PDF and (possibly) PS. So my thinking is that if we missed a thing or two in fonts and graphics, we'll just deal with it as it comes. But with PDF and PS, we run the risk of losing some large chunks of utility if we don't have either 1) someone familiar with the changes guide the porting, or 2) someone go through some detailed diff work to try to ferret out the changes. I just want to make sure that my insistence in starting with the maintenance branch code instead of HEAD isn't perceived as underestimating the difficulty in that approach. It is ugly -- I just think it is less ugly than the alternatives. Victor Mote
RE: FOray 0.1 release
Chris, Jeremias, and anyone else looking at FOray code: I have created the following branch in FOray's CVS that you will want to use for your evaluation: rel_0_1_branch I have started some other changes in the root that should probably be evaluated separately. I apologize for the inconvenience. I really should have done this from the start. Victor Mote
RE: FOray 0.1 release
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. 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. 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. 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. 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, 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. Victor Mote
Re: FOray 0.1 release
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 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. 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. When the XML Graphics project is set up I hope we can soon talk about the details of my ideas. I'd love to have you with us to work on the shared components. On 13.07.2004 22:40:43 Victor Mote wrote: FOP Devs: I am pleased to announce the release of FOray 0.1 alpha 1. This release is only useful to FOP developers. Some useful information about the release can be found in these places: http://foray.sourceforge.net/module/font/index.html http://foray.sourceforge.net/module/font/release.html Since it is developers-only, I have not prepared any downloadable packages. You will need to use CVS to get the code. This is available here: http://sourceforge.net/cvs/?group_id=109663 Probably the most efficient way to proceed is for Chris to do the initial evaluation work. I can support him off-line, and probably will need to add some doc as a result of his work. Then any others who wish to look at it will have an easier time. To cleanly get Fonts isolated, I had to isolate PDF, and to isolate PDF, I had to isolate Graphics. So there are actually three FOray modules at the moment (plus Common). Please remember that this release is a no-feature release, but is intended to address architectural issues only. The main purposes of the release are 1) to try to find out whether anything has broken, and 2) to get comments on the general design. Implied within FOray itself is a desire on my part to start getting code released again. I realize that there are several views of how best to get that done, and that FOray might be viewed as a distraction by some. If that is the prevailing view, and FOP has no desire to release this code under any circumstances, then you can save Chris a lot of trouble by reaffirming the status quo now. This will put the burden on FOray to start releasing essentially a competing product, which I am not eager to do. (This may happen eventually anyway if I have time to pursue the modular design that I think is important, but it is just as likely that a FOP 1.0 release will make such an effort unnecessary). As a friend of FOP I have opinions on what you should do, but my role here is different, and I will try to remain neutral, providing information when needed. I'm really just a guy trying to get some work done -- if it helps you, good; if not, that is OK too. Please let me know if there is anything I can do to help. Victor Mote Jeremias Maerki
Re: FOray 0.1 release
Victor Mote wrote: FOP Devs: I am pleased to announce the release of FOray 0.1 alpha 1. This release is only useful to FOP developers. Some useful information about the release can be found in these places: http://foray.sourceforge.net/module/font/index.html http://foray.sourceforge.net/module/font/release.html Since it is developers-only, I have not prepared any downloadable packages. You will need to use CVS to get the code. This is available here: http://sourceforge.net/cvs/?group_id=109663 Hi Victor: Great that you've managed to create a Font API. Probably the most efficient way to proceed is for Chris to do the initial evaluation work. I can support him off-line, and probably will need to add some doc as a result of his work. Then any others who wish to look at it will have an easier time. Yes, I will gladly take a look at some point over the next few days. snip/ Implied within FOray itself is a desire on my part to start getting code released again. I realize that there are several views of how best to get that done, and that FOray might be viewed as a distraction by some. If that is the prevailing view, and FOP has no desire to release this code under any circumstances, then you can save Chris a lot of trouble by reaffirming the status quo now. This will put the burden on FOray to start releasing essentially a competing product, which I am not eager to do. (This may happen eventually anyway if I have time to pursue the modular design that I think is important, but it is just as likely that a FOP 1.0 release will make such an effort unnecessary). As a friend of FOP I have opinions on what you should do, but my role here is different, and I will try to remain neutral, providing information when needed. I'm really just a guy trying to get some work done -- if it helps you, good; if not, that is OK too. I am clear on FORay's stance with regard to FOP, and I also hope that some of your work can benefit FOP too. Thats why I dont mind evaluating what you've done so far. Chris
