Hi Ludovic, 2008/6/6 Ludovic Dubost <[email protected]>:
I have a few questions about JODConverter..
- I see you already have a web service. How about a nice REST api for that web service, including username/password ?
The web service 'protocol' used by JODConverter 2.2 is documented at http://www.artofsolving.com/node/15 It's like that because it seemed the simplest solution for the purpose of sending a document and getting back a converted one. I guess proper REST would involve (doing a PUT rather than a POST and) storing the file somewhere and give it a URI so it can be retrieved at any later point. It's something I consider beyond the scope of the converter service, something more appropriate for a full document management system. But of course I'm open to suggestions. Same thing for authentication, I don't think it's the responsibility of the converter service to provide it, people can add it on top of JODConverter by configuring HTTP basic auth in their front-end Apache server, or adding a <security-constraint> in web.xml, or Spring Security, etc. - Are you handling a conversion queue ? JODConverter 2.2 uses standard Java synchronisation to serialise access to OOo, because OOo multi-threading is unreliable, so only one conversion is performed at a time. JODConverter 3.0 uses Java 5 concurrency to provide more flexibility, e.g. specifying lock timeouts, and also let you run multiple OOo processes to increase scalability. - How do you handle OO not coming back from the conversion or crashing ? JODConverter 2.2 doesn't deal with that case at all, the service will just become unavailable until you manually restart OOo. That's the strong case for JODConverter 3.0 - http://jodconverter.wiki.sourceforge.net/v3.0
- Do you have caching of your conversions ?
Nope. As mentioned my philosophy is that the converter should only concern itself with doing conversions. But again I'm open to discussion. Cheers Mirko
Ludovic
Mirko Nasato wrote:
Hi all,
I'd certainly be happy to add XWiki to the list of other open source projects that use JODConverter and provide suggestions if needed.
I see you mention xhtml... well the OOo xhtml filter is quite limited currently. For one it doesn't export embedded images[1]. But it's going to see big improvements with OOo 3.0.
You may also be interested to know that there's a new major version of JODConverter[2] in development.
Cheers
Mirko
-- [1] http://qa.openoffice.org/issues/show_bug.cgi?id=22012 [2] http://jodconverter.wiki.sourceforge.net/v3.0
2008/6/5 Luis Arias <[email protected]>:
Cool ! I'm glad I could be of help ! Mirko will be happy to know you are working with his code. Putting him on copy.
Luis
On Wed, Jun 4, 2008 at 11:13 PM, Ludovic Dubost <[email protected]> wrote:
Thanks Luis,
This is indeed exactly what we need.. a web service and a java API at the same time Wang you should use this.. expose it as an XWiki plugin with a configuration option to run embed or connect to an existing web service.
My idea is that we ship XWiki configured by default to talk to a server that we would host on our platform.
Ludovic
Luis Arias wrote:
Hi everyone,
Sorry to pop in, but I imagine you are aware of Mirko's JODConverter and JODReports:
If not I thought it might be useful in the context of your discussion.
His
code is used by Nuxeo, Alfresco, and others and is very simple to use. JODCOnverter plugs into OO running in server mode.
Good luck, Luis
On Wed, Jun 4, 2008 at 8:37 PM, Vincent Massol <[email protected]>
wrote:
On Jun 4, 2008, at 8:33 PM, Sergiu Dumitriu wrote:
> Vincent Massol wrote: > > >> On Jun 4, 2008, at 7:30 PM, Ludovic Dubost wrote: >> >> >> >>> I agree, >>> >>> First you need to package your code as an XWiki plugin that can be >>> called. >>> This plugin should have as many conversion possibilities. >>> >>> doc or office -> xhtml >>> xls -> xhtml >>> doc -> openoffice >>> openoffice ->doc >>> doc -> pdf >>> html -> pdf >>> etc.. >>> >>> >> hmm not sure. We only need xhtml I think since it's then the role
of
>> the XWiki HTML Parser to generate an internal DOM. Once we have that >> DOM we benefit from all the renderers (PDF, XHTML, RTF, Latex, etc). >> >> >> > I second Vincent, for the moment the priority is to have wiki > documents. > But then I agree with Ludovic, that it would be better to convert > attachments to different formats using the OOo codebase. The pdf > export > done now affects only wiki documents, not attachments, and going > through > a long chain of conversions (.doc -> wiki -> xhtml -> xsl-fo -> pdf) > will only introduce possible problems at each conversion, while a > direct > conversion doc -> pdf using the (better) OOo code is simpler and > easier. > We can (and should) keep the current PDF export mechanism for wiki > documents, though. > > I think we should make the PDF export a secondary priority and get the rest working for now. Let's revisit it when all the rest is working fine.
Thanks -Vincent
>>> Concerning xls I think we should look into having an import that >>> does >>> not go through html >>> We might want to write xls to wiki table >>> >>> >>> > +1 to this one, too. I think that direct data manipulation through OOo > is better than reverse-engineering html, and not just for > spreadsheets, > but other types of documents. > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Luis Arias +33 6 14 20 87 93 skype : kaaloo
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs