Hi Peter, On 2011-01-03 at 21:06 +0100, Peter Jentsch wrote:
> I'm attaching a patch I somehow managed to patiently pull out of git :-) > > As I'm new to C++, libxslt, git and a few other things involved in > creating the patch I feel it must be full of warts and cause random > crashes, but it seems to work and might be useful anyway. Thanks a lot - looks great on the first sight :-) Let me look a bit better (unless somebody else volunteers to do a deeper review?) now. Before pushing it to the master branch, I'd like to ask you for 2 things: License: Please, do you agree to license under the MPL / LGPL / GPL combo, as recommended in http://cgit.freedesktop.org/libreoffice/build/tree/COPYING.NEWFILES Purpose documentation: Can you please add a brief description of the new classes in the header? Just something like: /** The Reader class has to be a separate thread because of this and that. */ class Reader: public osl::Thread { ... } [So - don't describe the obvious facts, just higher level / design decisions.] > Basically, the patch provides an alternative service implementation > to be used by XSLTFilter.cxx. Use of the libxslt implementation can be > triggered by adding "libxslt" as second parameter to the "UserData" > configuration of an xslt filter. This second parameter is currently > unused for xslt filters. > > To completely remove the java dependency for xslt filters, the > xsltvalidation service would also need to be replaced by an > implementation based on libxslt. > > Also, the Office 2003 XML export filters use a saxon extension > implemented in Java, which needs to be replaced by a libxslt extension > if Office 2003 XML export should be supported without Java, too. > > The flat xml export could be implemented as a pure C++ xml Filter > indendendently of the xslt filter, as proposed in the SDK examples, I > suppose, and I'd like to do that next. In fact, this perfectly fits as the documentation - so I think it would be enough to paste most of this mail to the appropriate places. > I personally like the idea to make the implementation to use > configurable, instead of completely removing the Java based xslt filter > implementation. The problem then is that we would have 2 things to maintain; so I think it is better to go with your implementation, and get rid of the Java implementation for good. [But of course, short term we can live with both, no problem with that.] Thank you a lot, Kendy _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
