DO NOT REPLY [Bug 35998] - [PATCH] rtflib independance from FOP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35998. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35998 [EMAIL PROTECTED] changed: What|Removed |Added Status|VERIFIED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: API discussion (revived)
The Web Maestro wrote: On Aug 21, 2005, at 11:39 AM, Simon Pepping wrote: On Sun, Aug 21, 2005 at 08:29:03AM +0200, Jeremias Maerki wrote: On the other side, maybe we should really take the time to write up a short specification for the API and to have that voted on. After all, this is the main entry point into FOP. If anybody could take the lead on this, I'd be very grateful as I have my hands full enough already. I can still do it myself, if really nobody can be found to do it. But I'd really not do all that stuff in a lonely rider fashion. I am afraid I have no strong feelings about this issue. So I'll go with your lonely rider stuff or what you and Manuel come up with. Simon I too am not worried about the API/CLI. Mainly because I don't see a lot wrong with the current one! But if you guys think it need re-organising thats fine, so long as no functionality is lost, I'm happy. I'll second that. I don't have much 'energy' on this. I will say that it's nice to see Manuel's enthusiasm. We should've hinted at an upcoming 1.0 release long ago! ;-) Jeremias' announcement about an upcoming release of HEAD was more than a hint. It's real and coming in a few weeks time :-) Chris
Re: StAX, JAXP 1.4
Elliotte Harold wrote: Peter B. West wrote: Fopsters, Some of you may be aware of the activity going on around StAX. Java 1.6 (Mustang) was to have included JAXP 1.4, but that looks to be on hold until Dolphin. However, StAX will be part of it, and soon enough, SAX will be a dim memory. Yeah, right. I give this claim about as much credence as I gave the claims that schemas were going to replace DTDs. StAX isn't as disastrously bad as schemas were, but it certainly hasn't justified the hype either. So far I've seen approximately no evidence that it provides any noticeable improvements over SAX. Some people find StAX easier to use the SAX for some use cases, but not all. I suspect Sun never saw the performance improvements they were hoping for from StAX which is why they're now off and running up another wrong path called Fast Infoset. (I was just looking at some 3rd party performance numbers on that this morning, and guess what? It isn't working out either.) I don't think SAX is the ultimate in XML performance, but I suspect even a factor of two improvement over SAX is going to require something a lot more radical than StAX. Elliotte, So I exaggerated. But how many better applications can you find me for StAX than processing XSL-FO? If StAX has no application here, it has no application. Is that what you're saying? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
JAXG snapshot available (was: Re: API discussion (revived))
I've cleaned up JAXG and published it on my website: http://www.jeremias-maerki.ch/dev/jaxg/ Comments are welcome. Jeremias Maerki
Re: JAXG snapshot available
Jeremias Maerki wrote: I've cleaned up JAXG and published it on my website: http://www.jeremias-maerki.ch/dev/jaxg/ Comments are welcome. I thought the main problem with the current proposal was Sun's objection to the name JAXG? Aren't you going to rename it before proceeding further? Chris
Re: StAX, JAXP 1.4
Peter B. West wrote: So I exaggerated. But how many better applications can you find me for StAX than processing XSL-FO? If StAX has no application here, it has no application. Is that what you're saying? You're asking the question backwards. We should not be asking, Is XSL-FO the best possible use case for StAX? We should be asking, Is StAX the best possible API for XSL-FO? One certainly good do write FOP on top StAX, but you can also do it with SAX; and since it's already working with SAX I see no particular reason to throw away the working SAX code and replace it with StAX. If we were starting from scratch, and if the developers were more familiar with StAX than SAX, and if StAX parsers were as mature, proven, and ubiquitous as SAX parsers, then writing FOP on top of StAX might be reasonable. However none of that's the case. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: JAXG snapshot available
On 22.08.2005 12:57:22 Chris Bowditch wrote: Jeremias Maerki wrote: I've cleaned up JAXG and published it on my website: http://www.jeremias-maerki.ch/dev/jaxg/ Comments are welcome. I thought the main problem with the current proposal was Sun's objection to the name JAXG? Aren't you going to rename it before proceeding further? I want to but I still don't have the ideal name. I have lots and lots of suggestions but so far I couldn't make up my mind. Lots of problems like name collisions, almost-references to existing projects and products. JAXG would really be ideal but the only way to safely proceed this way is to start a JSR but I can't and won't do that alone. I'd need at least two or three people who'd support that and have time to go after it. The only good thing is that I think the package names can stay constant: org.xml.graphics. Adoption is probably not impeded by that at least. Jeremias Maerki
Re: StAX, JAXP 1.4
Elliotte Harold wrote: Peter B. West wrote: So I exaggerated. But how many better applications can you find me for StAX than processing XSL-FO? If StAX has no application here, it has no application. Is that what you're saying? You're asking the question backwards. We should not be asking, Is XSL-FO the best possible use case for StAX? We should be asking, Is StAX the best possible API for XSL-FO? One certainly good do write FOP on top StAX, but you can also do it with SAX; and since it's already working with SAX I see no particular reason to throw away the working SAX code and replace it with StAX. If we were starting from scratch, and if the developers were more familiar with StAX than SAX, and if StAX parsers were as mature, proven, and ubiquitous as SAX parsers, then writing FOP on top of StAX might be reasonable. However none of that's the case. But of course, I'm talking about Folio, which was built on a pull-parsing model before I had ever heard of pull-parsing, because it was the screamingly obvious thing to do. It gives me acute pleasure to see my original design decisions vindicated by the the development of the StAX API, and the current surge of interest. So, all of this, and more, _is_ the case. My invitation stands. Don't let your feet get wet, Elliotte. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: StAX, JAXP 1.4
Peter B. West wrote: But of course, I'm talking about Folio, which was built on a pull-parsing model before I had ever heard of pull-parsing, because it was the screamingly obvious thing to do. It gives me acute pleasure to see my original design decisions vindicated by the the development of the StAX API, and the current surge of interest. So, all of this, and more, _is_ the case. My invitation stands. I haven't looked at Folio yet. Perhaps it's screamingly obvious that it needs a pull model. If so it's the first such application I've encountered. The really useful pull models are implemented on top of tree structures, and provide random access. I've yet to see a case where a one-way streaming pull parser did anything that couldn't be accomplished equally easily and efficiently with a push parser. The primary benefit to pull parsers is that some developers either don't understand or simply don't like the observer design pattern as embodied in push parsers, and prefer the iterator design pattern as embodied in pull parsers. Whatever floats your boat. However there's no evidence that either pattern is in any way fundamentally superior to the other, except as a matter of developer taste. As a practical matter, existing SAX parsers are much better optimized and debugged than existing StAX parsers. They're simply a more mature product. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
