Re: ANN: FOray
Victor Mote wrote: Simon Pepping wrote: I sympathize with this goal as well. I realize that that is not quite in line with my reaction to Glen's recent patch. I agree with Chris and Glen that it is not currently a key goal for FOP. And since we do not have a strong proponent and architect of a modular design, there is little point in leaving bits and pieces in the code. But in the longer run, I consider putting the FOP code in a modular structure as a desirable thing. If you guys are as close to having LayoutManager working as has been stated in this thread (and I hope you are), then I agree that modularization would not be the top priority. It is not an end in itself, but a means to an end. When FOP was internally forked 2 1/2 years ago, the only thing that needed to be rewritten from scratch was layout, but the whole project was forked instead. Modularization would have prevented that, and allowed releases to continue even though a chasm was being created and filled simultaneously. The whole nature of refactoring anything is that you do it before you do the real work. That is where FOray starts. That decision 2.5 years ago has cost FOP dearly. It is also much easier to see in hindsight. Given where FOP is today, I just want to see the last 5 issues fixed/implemented and we can do a release and get FOP back on track. The real question on modularity was never whether it should be a priority, but whether it hurt the project. On open-source projects, priorities are really set by each individual. You fix the thing that hurts the most at the moment, and that might be different for each developer. If I am working on A, and you are working on B, as long as your work on B isn't bad for the project as a whole, I have no right to complain. Nobody has yet put forth a good argument against modularization, but it was opposed anyway. So now we'll have a chance to test it in the real world. I dont recall modularizarion being opposed. It was more a case of Joerg saying it would be a challenge and no one else stepping up to support your proposals. From my point of view this was mainly due to me thinking FOPs priority is to get the last few bits of layout done so a release is possible. I'm certainly not against modularization, I think it would be beneficial, but would prefer to see effort going into finishing layout at this time. Once weve done an initial release from the development code, then modularization will be a more attractive proposal. Generally you are right in what you say that priorities are down to individuals. But given the situation FOP is currently in, I hope most people can see why I think No.1 priority is to finish layout. Consider this -- what if the XSL spec hadn't been split into two pieces? Would the part that we call Xalan today have its development stalled because layout is stalled? If XSL-T and XSL-FO were all in one spec, would we be smart enough to break the implementation into the two projects that it is in today? All we are really talking about here is the principle of encapsulation writ large. Modularization is in general a good idea, I just think its not the right time to be doing this within FOP. Perhaps modularization should have been done 2.5 years ago before branching the project. Chris
RE: ANN: FOray
Arnd Beißner wrote: Peter B. West [EMAIL PROTECTED] wrote on 19.05.2004 00:12:41: I think you are talking about different modularisation contexts here. You might want to clarify this part of the discussion with Victor. I really thought it was about the pluggable layout that Victor brought up a long time ago. If not, just forget what I said. 8-) You are correct that LayoutStrategy, aka pluggable layout was at the heart of the topic. And Peter is correct that the scope of modularization in LS was at a different level than you were talking about. But I don't understand Peter's point at all. If separation of concerns between page layout and block layout is beneficial, then how much more so that neither of them should be embedded in the FOTree??!! (Which FOP developers decided to redo just last week). The fact that you are successfully modularizing trees into branches and leaves is no argument against FOP modularizing the forest into trees. Victor Mote
RE: ANN: FOray
Chris Bowditch wrote: I dont recall modularizarion being opposed. It was more a case of Joerg saying it would be a challenge and no one else stepping up to support your proposals. When I left the project, there were 5 active developers, 1 for, 2 against, 2 neutral or silent. Joerg and I never disagreed on the difficulty of the project, and it was not an impediment to me that others were busy doing other things. But when active opposition emerged, it was time to cut bait. This is all water under the bridge, and I only mention it because you challenged my assertion. If FOray has any success at all, you all will have another opportunity to address the issue. Victor Mote
Re: ANN: FOray
Victor Mote wrote: Dear FOP Developers: Hi Victor - welcome back. I was saddened by your decision to leave FOP. After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ Ive taken a look and it all seems to make sense. The main reason for this is that, at the moment anyway, my development goals are quite different from those of FOP's development team. It is likely that my return to FOP development would be a net disruption to the project, which is not my intent. Instead, my hope is that this vehicle will allow me to continue to get my real work done and still cooperate with the FOP development team. I do understand why you have decided to start FOray. Although modularisation is a nice feature, I dont see it as a key goal for FOP. FOP's primary objective is to achieve a working layout. The main things needed to achieve this are listed here: http://xml.apache.org/fop/design/layout.html#status I hope that no one will think that I am recruiting here. I simply thought it would be rude for you to hear about this some other way. I wish you all success. No I dont think that, it is very polite of you to let us know. I cant speak for the team as a whole, but I hope that we will be able to cooperate to a high extent. Chris
Re: ANN: FOray
Peter B. West [EMAIL PROTECTED] wrote on 18.05.2004 05:59:20: project. The situation with FOray is more complicated. I don't know whether it is Victor's intention to fork from HEAD and continue the development along the lines he has previously discussed, or to attempt to integrate HEAD and the maintenance branch in some way. In any case, what Victor is doing will closely parallel the HEAD development, and this, combined with the possibility of some financial support, has a great potential to de-stabilise FOP. I'm not saying this as a criticism of Victor, but as a bald statement of the reality. Some elaborations on this from my side. Please feel free to ignore it entirely. About 18 months ago, I was in a situation similar to Victor's. I wanted to get a few things done in FOP and did some patches. Like all of you here I realized that FOPs (maintenance) internal structure wasn't all that great. However, unlike the committers here I thought that refactoring the maintenance branch would have been the way to go. My gut feeling was that, given the time available to the committers and the non-existence of a strong head developer, the re-implementation would either take extremely long or fail. Since this was really a gut feeling based on the discussions here and my professional experience, I didn't really speak up, because I didn't really have anything in my hands to prove my point and I also wasn't a stakeholder - so to speak. Maybe that was wrong, maybe not. Well, I discussed a little with Nicola as another interested bystander at that time. Here's an excerpt from my mail that I think still applies: Truth to tell, my greatest fear concerning FOP right now is not the license but that the people involved in the redesign take too long because they don't have enough time. In commercial projects, I've seen the following happen many times: 1. Project A starts and is moderately successful 2. Implementation learnings from A and new requirements toggle the decision for a complete redesign. 3. Project B is kicked off as a result, but progresses slowly (for whatever reasons) 4. A is still in use but needs fixes and some small enhancements, yielding A' 5. Time goes on, A' and B progress further. 6. Someone comes up with a carefully refactored version of A' and B is stopped. I truly hope this doesn't happen with the seemingly long ongoing FOP redesign. This was two years ago, but I think I can still subscribe to it. About 18 months ago, my options were: 1. Get into the hot-headed discussions an try a turn-around to refactoring 2. Fork off an 0.20.3 branch (at that time) on SourceForge (like Victor did now) 3. Write my own XSL formatter. I pretty soon discarded 1. and toyed with 2. However, since sometimes I still have a let's storm that hill attitude and were also pretty familiar with writing text formatters and PS and PDF emitters, I opted to do 3, but to do it as a fun project with an open goal since I didn't have all that much spare time beside my business. Kind of a let's just see what happens project. So what happened was: I now have an XSL formatter that is in my estimation further along than the FOP redesign and that does most things that 0.20.5 does and a lot of things that 0.20.5 does not. I confess that so far, I did borrow the TrueType font reader from FOP. What am I going to do with it? Well, it's not really decided yet. The most likely scenario is to make it a commercial product. BTW: why was I fast? I'm good (like you), I had experience in many of the areas involved, and - very important - I didn't need to discuss my architectural decisions because I did it alone. I had fun. So why am I writing this? First, I very much wish the FOP team and the project to succeed. Even I my pet project is ultimately successful and even if it's a commercial success I firmly believe that we need an open source XSL formatter under the Apache license. Second, maybe to give you second thoughts about what you and Victor are doing. My personal impression and also my recommendation is to: Model A: Let one strong developer with resonable time on his hands drive the development of the redesign until it has so far progressed that it's usable for people currently using 0.20.5. Model B: Refactor the maintenance branch. This keeps more users and therefore more possible contributors on the bandwagon. Refactoring is tedious and needs experience, but you get that experience quickly and the motivation stays over time. Also, the maintenance branch source code is not *that* bad. Yes, it badly needs refactoring in most places, but it's not beyond repair. Since I don't see Model A for FOP currently (no strong developer WITH enough time on the horizon), I believe Model B is what would work best. Your existing development model for FOP 1.0 is taking too long IMO. This is not a criticism of any of you, but a personal assessment of what I think can be achieved with the time
Re: ANN: FOray
[EMAIL PROTECTED] wrote: Some elaborations on this from my side. Please feel free to ignore it entirely. Thanks for speaking up. Just because you are not a committer, doesnt mean your opinion doesnt matter. This is open source way. The project is owned by everyone. snip/ 5. Time goes on, A' and B progress further. 6. Someone comes up with a carefully refactored version of A' and B is stopped. This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo We have in fact completed the first item. Once we have completed the other tasks the redesign wont be far behind 0.20.5. Once we do a release, I believe the project will gain some momentum. So what happened was: I now have an XSL formatter that is in my estimation further along than the FOP redesign and that does most things that 0.20.5 does and a lot of things that 0.20.5 does not. I confess that so far, I did borrow the TrueType font reader from FOP. What am I going to do with it? Well, it's not really decided yet. The most likely scenario is to make it a commercial product. BTW: why was I fast? I'm good (like you), I had experience in many of the areas involved, and - very important - I didn't need to discuss my architectural decisions because I did it alone. I had fun. I'm impressed. You must have a lot of spare time, and be a very talented programmer. I would be grateful if you could help with any of the tasks listed above, so we can get a release of the redesign and overcome FOP's current dilema. Model A: Let one strong developer with resonable time on his hands drive the development of the redesign until it has so far progressed that it's usable for people currently using 0.20.5. Model B: Refactor the maintenance branch. This keeps more users and therefore more possible contributors on the bandwagon. Refactoring is tedious and needs experience, but you get that experience quickly and the motivation stays over time. Also, the maintenance branch source code is not *that* bad. Yes, it badly needs refactoring in most places, but it's not beyond repair. The redesign project is further along than you might think. 2003 was really bad for the redesign, absolutely zilch progress was made on layout. However, there has been some progress since the end of last year. So if we can just finish the tasks listed above, FOP should be back on the road to success. I'm certainly not keen to drop the redesign so close to the finish line. Perhaps 12 months ago I would have been inclined to agree, but not now. snip/ Like two years ago, I still don't feel all that comfortable about speaking up on this. After all, it's *your* project, and what the f*** do I have to say about it. Ok, this time I decided to do it. Please don't be offended - it's really meant as a personal opinion from an interested bystander. I hope you can accept it as such. I'm glad you have spoken up. And this goes for any other silent folks out there considering the same options. Please speak up - every opinion counts, the project belongs to the community, not just to the committers. Chris
Re: ANN: FOray
Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33: This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo One comment on the todos: - border-collapse is both important and difficult. I am still fiddling with details of the spec. I suggest ugrading the priority. Not supporting border-collapes yields ugly output. We have in fact completed the first item. Once we have completed the other tasks the redesign wont be far behind 0.20.5. Once we do a release, I believe the project will gain some momentum. That I agree with. May I was too pessimistic regarding the progress. I'm impressed. You must have a lot of spare time, and be a very talented programmer. I would be grateful if you could help with any of the tasks listed above, so we can get a release of the redesign and overcome FOP's current dilema. Well, unfortunately not so much spare time, but as I said, doing it alone really, really helps. And I very much tried to aggregate as much spare time as possible into full dev-only days. That helps, too. With the same background, most of you committers could have done the same. If you look at it, most successful projects initially had 1 or 2 people at the start who did the core work, and then others joined to make it complete. If I had joined the redesign team, FOP wouldn't be much farther than it is now, because most of my time would have gone to discussions, which in turn would also have taken up other committer's time. What I *can* offer to contribute is discussion about the FO spec or about implementing PS oder PDF output. This is a concern that we probably share and that needs discussion in any case. However, for actual implementation discussions I feel a little reluctant. If my pet project becomes a product in the future, we will have the same issues coming up here that we had with the RenderX guy speaking up here recently. This is not what I want - though I think what he did was perfectly ok, well-meaning and to be applauded. If I recall correctly, the uproar was resolved, the RenderX guy got his deserved apology, but the consensus was that the FOP code should be kept clean from competitor's code or even ideas. If I remember that correctly and this still stands, then I would rather not discuss algorithms here. Have a nice day out there, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
Re: ANN: FOray
[EMAIL PROTECTED] wrote: Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33: This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo One comment on the todos: - border-collapse is both important and difficult. I am still fiddling with details of the spec. I suggest ugrading the priority. Not supporting border-collapes yields ugly output. What I forgot to say is that I think we should do an initial release of FOP after doing just High priority TODO items. Yes, ugly output can be caused without border collapse, but yet RenderX's XEP doesnt have border collapse, so I dont see an immediate need for it. After all, output only looks ugly if you specify borders on every cell edge, with careful writing of the FO, the output can still look good without border collapse. Well, unfortunately not so much spare time, but as I said, doing it alone really, really helps. And I very much tried to aggregate as much spare time as possible into full dev-only days. That helps, too. With the same background, most of you committers could have done the same. If you look at it, most successful projects initially had 1 or 2 people at the start who did the core work, and then others joined to make it complete. If I had joined the redesign team, FOP wouldn't be much farther than it is now, because most of my time would have gone to discussions, which in turn would also have taken up other committer's time. Perhaps, but perhaps not. As long as you dont make major changes, then its possible to proceed without seeking group consent on every little item. Thats what I'm trying to do. Work towards a working layout a bit at a time using the existing redesigned framework. What I *can* offer to contribute is discussion about the FO spec or about implementing PS oder PDF output. This is a concern that we probably share and that needs discussion in any case. However, for actual implementation discussions I feel a little reluctant. If my pet project becomes a product in the future, we will have the same issues coming up here that we had with the RenderX guy speaking up here recently. This is not what I want - though I think what he did was perfectly ok, well-meaning and to be applauded. If I recall correctly, the uproar was resolved, the RenderX guy got his deserved apology, but the consensus was that the FOP code should be kept clean from competitor's code or even ideas. If I remember that correctly and this still stands, then I would rather not discuss algorithms here. Fair enough. That was an unfortunate affair, and one I'm keen not to repeat. Chris
border-collapse WAS: Re: ANN: FOray
Chris Bowditch [EMAIL PROTECTED] wrote on: 18.05.2004 14:31:39: What I forgot to say is that I think we should do an initial release of FOP after doing just High priority TODO items. Ok, that changes things, of course. Yes, ugly output can be caused without border collapse, but yet RenderX's XEP doesnt have border collapse, so I dont see an immediate need for it. After all, output only looks ugly if you specify borders on every cell edge, with careful writing of the FO, the output can still look good without border collapse. True. Well, partially so. If you have, for example, tables with small fonts and lots of narrow columns and horizonal space is scarce, then it gets increasingly difficult to create good-looking table borders between columns without border-collapse. Maybe my focus is shifted a little too much on the actual problems that I have with my customer's requirements. Also, in my formatter, I want to implement the collapsing model early, because it's default in FO and because I want to get everything out of the way that I don't have an immediate solution for. Makes me nervous otherwise. As for FOP, ok, I do agree that getting a formatter out that is at least as good as 0.20.5 may take priority. Bye, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH Bahnhofstr. 3, 71063 Sindelfingen, Germany Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99 Mobile: +49-173-3016917 Chris Bowditch [EMAIL PROTECTED] schrieb am 18.05.2004 14:31:39: [EMAIL PROTECTED] wrote: Chris Bowditch [EMAIL PROTECTED] wrote on 18.05.2004 12:03:33: This is very true, I also have the same concerns, which is why I have set out some simple objectives that must be met before the redesign is ready for an initial release. See here: http://xml.apache.org/fop/design/layout.html#status-todo One comment on the todos: - border-collapse is both important and difficult. I am still fiddling with details of the spec. I suggest ugrading the priority. Not supporting border-collapes yields ugly output. What I forgot to say is that I think we should do an initial release of FOP after doing just High priority TODO items. Yes, ugly output can be caused without border collapse, but yet RenderX's XEP doesnt have border collapse, so I dont see an immediate need for it. After all, output only looks ugly if you specify borders on every cell edge, with careful writing of the FO, the output can still look good without border collapse. Well, unfortunately not so much spare time, but as I said, doing it alone really, really helps. And I very much tried to aggregate as much spare time as possible into full dev-only days. That helps, too. With the same background, most of you committers could have done the same. If you look at it, most successful projects initially had 1 or 2 people at the start who did the core work, and then others joined to make it complete. If I had joined the redesign team, FOP wouldn't be much farther than it is now, because most of my time would have gone to discussions, which in turn would also have taken up other committer's time. Perhaps, but perhaps not. As long as you dont make major changes, then its possible to proceed without seeking group consent on every little item. Thats what I'm trying to do. Work towards a working layout a bit at a timeusing the existing redesigned framework. What I *can* offer to contribute is discussion about the FO spec or about implementing PS oder PDF output. This is a concern that we probably share and that needs discussion in any case. However, for actual implementation discussions I feel a little reluctant. If my pet project becomes a product in the future, we will have the same issues coming up here that we had with the RenderX guy speaking up here recently. This is not what I want - though I think what he did was perfectly ok, well-meaning and to be applauded. If I recall correctly, the uproar was resolved, the RenderX guy got his deserved apology, but the consensus was that the FOP code should be kept clean from competitor's code or even ideas. If I remember that correctly and this still stands, then I would rather not discuss algorithms here. Fair enough. That was an unfortunate affair, and one I'm keen not to repeat. Chris
Re: ANN: FOray
On Tue, May 18, 2004 at 09:16:23AM +0100, Chris Bowditch wrote: Victor Mote wrote: Dear FOP Developers: Hi Victor - welcome back. I was saddened by your decision to leave FOP. After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ Ive taken a look and it all seems to make sense. I agree. Goal 1. provide a place where enhancements can continue to be made to the working branch of FOP. I sympathize with this goal. The position of the FOP team over the past years w.r.t. the maintenance code is rather strict. It sort of disallows commits to the maintenance branch, even if non-team members come up with a patch. In view of the long time it takes to release a usable version of the development code, it may be wiser to relax this policy, and cooperate on improvements to the maintenance code. 2. modularize FOP's design I do understand why you have decided to start FOray. Although modularisation is a nice feature, I dont see it as a key goal for FOP. FOP's primary objective is to achieve a working layout. The main things needed to achieve this are listed here: http://xml.apache.org/fop/design/layout.html#status I sympathize with this goal as well. I realize that that is not quite in line with my reaction to Glen's recent patch. I agree with Chris and Glen that it is not currently a key goal for FOP. And since we do not have a strong proponent and architect of a modular design, there is little point in leaving bits and pieces in the code. But in the longer run, I consider putting the FOP code in a modular structure as a desirable thing. Meanwhile I will keep adding my small contribution to the layout system of the development code. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: ANN: FOray
Simon Pepping wrote: 2. modularize FOP's design I do understand why you have decided to start FOray. Although modularisation is a nice feature, I dont see it as a key goal for FOP. FOP's primary objective is to achieve a working layout. The main things needed to achieve this are listed here: http://xml.apache.org/fop/design/layout.html#status I sympathize with this goal as well. I realize that that is not quite in line with my reaction to Glen's recent patch. I agree with Chris and Glen that it is not currently a key goal for FOP. And since we do not have a strong proponent and architect of a modular design, there is little point in leaving bits and pieces in the code. But in the longer run, I consider putting the FOP code in a modular structure as a desirable thing. If you guys are as close to having LayoutManager working as has been stated in this thread (and I hope you are), then I agree that modularization would not be the top priority. It is not an end in itself, but a means to an end. When FOP was internally forked 2 1/2 years ago, the only thing that needed to be rewritten from scratch was layout, but the whole project was forked instead. Modularization would have prevented that, and allowed releases to continue even though a chasm was being created and filled simultaneously. The whole nature of refactoring anything is that you do it before you do the real work. That is where FOray starts. The real question on modularity was never whether it should be a priority, but whether it hurt the project. On open-source projects, priorities are really set by each individual. You fix the thing that hurts the most at the moment, and that might be different for each developer. If I am working on A, and you are working on B, as long as your work on B isn't bad for the project as a whole, I have no right to complain. Nobody has yet put forth a good argument against modularization, but it was opposed anyway. So now we'll have a chance to test it in the real world. Consider this -- what if the XSL spec hadn't been split into two pieces? Would the part that we call Xalan today have its development stalled because layout is stalled? If XSL-T and XSL-FO were all in one spec, would we be smart enough to break the implementation into the two projects that it is in today? All we are really talking about here is the principle of encapsulation writ large. Victor Mote
RE: ANN: FOray
Victor Mote [EMAIL PROTECTED] wrote on 18.05.2004 22:12:45: The real question on modularity was never whether it should be a priority, but whether it hurt the project. On open-source projects, priorities are really set by each individual. You fix the thing that hurts the most at the moment, and that might be different for each developer. If I am working on A, and you are working on B, as long as your work on B isn't bad for the project as a whole, I have no right to complain. Nobody has yet put forth a good argument against modularization, but it was opposed anyway. So now we'll have a chance to test it in the real world. In my formatter, I have implemented modularized layout. From the start, I was sceptical, and I was indeed tempted several times to throw the concept out of the window because it got in the way, but in the end it was always possible to maintain the separation of concerns between different kinds of layouters (BlockArea, Table, Page, and List for example) even though the interaction is admittedly complex. And, yes, it's sometimes hard to follow the logic by staring just at the code - which I prefer to using debuggers. To summarize my impressions from this: 1. I would do it again this way. 2. Maintaining clean separation of concerns *forced* me to redesign my layouter interfaces several times when I added new functionality, but I gained an implementation that I still understand clearly in its entirety even I cannot work on it for a week. 3. The only place where I have difficulties after some time off is my BlockAreaLayouter which is one very large chunk of code. Maybe it's even worth factoring out a LineAreaLayouter, though I'm not sure of it - the interaction is really tight. 4. It's too early to estimate how much modularized layout will hurt performance in the end. My gut feeling is: not much, and it's probably wort it. So, from my own experience I can only encourage you to go forward with your plan. For me, it worked so far. Let's see if the XSL rec turns up more nasty surprises... Bye, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
Re: ANN: FOray
[EMAIL PROTECTED] wrote: In my formatter, I have implemented modularized layout. From the start, I was sceptical, and I was indeed tempted several times to throw the concept out of the window because it got in the way, but in the end it was always possible to maintain the separation of concerns between different kinds of layouters (BlockArea, Table, Page, and List for example) even though the interaction is admittedly complex. And, yes, it's sometimes hard to follow the logic by staring just at the code - which I prefer to using debuggers. To summarize my impressions from this: 1. I would do it again this way. 2. Maintaining clean separation of concerns *forced* me to redesign my layouter interfaces several times when I added new functionality, but I gained an implementation that I still understand clearly in its entirety even I cannot work on it for a week. 3. The only place where I have difficulties after some time off is my BlockAreaLayouter which is one very large chunk of code. Maybe it's even worth factoring out a LineAreaLayouter, though I'm not sure of it - the interaction is really tight. 4. It's too early to estimate how much modularized layout will hurt performance in the end. My gut feeling is: not much, and it's probably wort it. So, from my own experience I can only encourage you to go forward with your plan. For me, it worked so far. Let's see if the XSL rec turns up more nasty surprises... Arnd, I think you are talking about different modularisation contexts here. You might want to clarify this part of the discussion with Victor. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
ANN: FOray
Dear FOP Developers: After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ The main reason for this is that, at the moment anyway, my development goals are quite different from those of FOP's development team. It is likely that my return to FOP development would be a net disruption to the project, which is not my intent. Instead, my hope is that this vehicle will allow me to continue to get my real work done and still cooperate with the FOP development team. I hope that no one will think that I am recruiting here. I simply thought it would be rude for you to hear about this some other way. I wish you all success. Victor Mote
Re: ANN: FOray
N.B. CC'd to [EMAIL PROTECTED] follow-up to fop-dev Victor Mote wrote: Dear FOP Developers: After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ The main reason for this is that, at the moment anyway, my development goals are quite different from those of FOP's development team. It is likely that my return to FOP development would be a net disruption to the project, which is not my intent. Instead, my hope is that this vehicle will allow me to continue to get my real work done and still cooperate with the FOP development team. I hope that no one will think that I am recruiting here. I simply thought it would be rude for you to hear about this some other way. I wish you all success. Without speculating at all about the reasons for Victor's decision, I can tell you that I have considered moving alt-design to SourceForge. The reasons are two-fold. Firstly, and most importantly, there is the remote possibility of garnering some financial support for alt-design's development. For those of you who may not yet know, SourceForge has implemented a means for donating to projects or specific developers. The attractions of this idea I need not comment on further. My second reason was to clear the FOP waters by physically separating alt-design from HEAD development. My approach to testing alt-design's layout is to use Java facilities as much as possible. This will cause even further divergence from HEAD, at least initially. Moving to SourceForge will clarify the development lines of FOP HEAD for those who are considering involvement in the project. Such a move would, obviously, have little or no impact on the main project. The situation with FOray is more complicated. I don't know whether it is Victor's intention to fork from HEAD and continue the development along the lines he has previously discussed, or to attempt to integrate HEAD and the maintenance branch in some way. In any case, what Victor is doing will closely parallel the HEAD development, and this, combined with the possibility of some financial support, has a great potential to de-stabilise FOP. I'm not saying this as a criticism of Victor, but as a bald statement of the reality. Many Apache projects seem to me to be wide open to this kind of de-stabilisation. Those projects with a large contingent of paid developers will not be affected; those with few of no paid developers (e.g. FOP) will be. I think the Board might better serve Apache by addressing this issue rather than some others on its current agenda. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: ANN: FOray
Peter B. West wrote: Such a move would, obviously, have little or no impact on the main project. The situation with FOray is more complicated. I don't know whether it is Victor's intention to fork from HEAD and continue the development along the lines he has previously discussed, or to attempt to integrate HEAD and the maintenance branch in some way. In any case, what Victor is doing will closely parallel the HEAD development, and this, combined with the possibility of some financial support, has a great potential to de-stabilise FOP. I'm not saying this as a criticism of Victor, but as a bald statement of the reality. How, if FOray will closely parallel the HEAD development could it possibly ha[ve] a great potential to de-stabilise FOP. If A = B, there could be no reason to switch from A to B. There seems to be implicit in your comment a nascent fear that maybe FOP really would benefit from being modularized. The initial, relatively small, fork will be from the maintenance branch. While it is being modularized, I will keep it in sync with my local copy of the FOP maintenance branch code, and hopefully submit a patch to that branch for your consideration. It is my hope that the benefits of this approach will be compelling enough that someone will want to roll it into HEAD as well, but that is your call, not mine. Depending on the success of this approach and its reception, I'll decide whether forking other pieces is needed (there are more extensive comments about this on the FOray home page.) Some of those forks may well be started with code from HEAD. WRT FOray's effect on FOP's stability, I don't see a need for any concern: 1. FOray's work is available to FOP (Apache 2 License), and I hope that FOP (among others) will use it. 2. Most importantly, if I thought that there were FOP developers who shared my zeal for modularizing FOP, I would a) not have left the project, and b) would even now be trying to reenter FOP to do the work there. The very brief review I took of the archives last week led me to believe that instead, the baby steps I had taken toward my goals are being dismantled. (I'm not offended, but merely reminded that I'm out of sync with you all.) Now, it is possible that there are some developers not currently involved with FOP that will be attracted to FOray. If there are compelling advantages to FOray's approach, then that is as it should be. Further, if there are people who see, for example, a benefit in having a freely-distributable alternative to JAI, who want it for a totally non-FOP related purpose, and who contribute to FOray, this seems like a net benefit to FOP. A similar situation would exist for someone who wants to build an FOTree for a voice-related application, use a well-crafted library of PDF-building routines, or write a layout engine that was optimized for some particular axis. There is no explicit intention to reconcile HEAD and maint. However, there are several sets of circumstances that could have that outcome as a byproduct. The biggest unknowns are the timing of LayoutManager's completion, and the speed of progress in FOray. WRT to the opportunity for funding, that had no part in my decision to use sourceforge. (I did opt-in to accept contributions -- why not?). And I doubt that serious funding will materialize through this channel. I would vastly have preferred to do this within FOP for many reasons. My second best choice was to find some other home on Apache for the independent modules, but I frankly don't have time to jump through all of their hoops. The great benefit to using sourceforge was the easy access. I can still get and receive the benefits of an open-source approach and let you guys stay on track with your work. Victor Mote
