When will JODConverter 3.0 beta become a final release?

[Hansen Candrawinata]

Hi Mirko,

Just would like to find out when you plan to finalize JODConverter 3.0
and make it an official release?

Thanks,
Hansen

[Mirko Nasato]

Hi Hansen,

There's no release date set I'm afraid. I'm not actually spending much
time on JODConverter these days.

Why do you ask? I mean, is there a specific feature you're waiting
for, or is it just that you'd like a "final" label?

Kind regards

Mirko

2009/11/23 Hansen Candrawinata <hansen.ca...@gmail.com>:

> --
>
> You received this message because you are subscribed to the Google Groups "JODConverter" group.
> To post to this group, send email to jodcon...@googlegroups.com.
> To unsubscribe from this group, send email to jodconverter...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jodconverter?hl=.
>
>
>

[Hansen Candrawinata]

Hi Mirko,

Thanks for replying. I just think that a final label is always good
to boost users' confidence in using the latest release of
JODConverter, especially when integrating it into a 'stable' software
project.

Having said that, I have a feature request that I would be grateful if
it can be added before the final 3.0 release. I have read other
people's requests and your responses about adding another method to
enable conversion from an InputStream to an OutputStream. You
mentioned that the reason the method was removed in the latest release
was because it used temporary files internally, so there's no
performance gained. I still don't get as to why temporary files have
to be used when you already have the contents in a stream object? Is
this a restriction of the OpenOffice service? Having the "convert
(InputStream source, OutputStream dest)" method would be helpful as it
avoids hitting the disk again when the contents of the file is already
stored in the memory. This is especially important for applications
that need to convert hundreds of documents and performance is of
critical issue.

Thanks,
Hansen

On Nov 24, 2:10 am, Mirko Nasato <mirko.nas...@gmail.com> wrote:
> Hi Hansen,
>
> There's no release date set I'm afraid. I'm not actually spending much
> time on JODConverter these days.
>
> Why do you ask? I mean, is there a specific feature you're waiting
> for, or is it just that you'd like a "final" label?
>
> Kind regards
>
> Mirko
>

> 2009/11/23 Hansen Candrawinata <hansen.candrawin...@gmail.com>:

[Mirko Nasato]

Hi Hansen,

2009/11/24 Hansen Candrawinata <hansen.ca...@gmail.com>:

>
> Thanks for replying.  I just think that a final label is always good
> to boost users' confidence in using the latest release of
> JODConverter, especially when integrating it into a 'stable' software
> project.
>

I know, but labels are always somewhat arbitrary. The license says the
software comes with "abolutely no warranties", whether it's labeled
"beta" or "final". ;-)

JODConverter 3.0 currently being "beta" doesn't mean that it doesn't
work, it just means that the API is still incomplete and could change.
In fact, it works well enough for my current projects, converting
thousands of documents a day.

So it's basically in a state where "it works for me", but it can't be
declared stable "for the general public" in terms of API,
documentation, etc. And, from a business point of view, working on
making it more suitable for the general public is a cost that doesn't
give me any returns, which is why it's not a priority for me.

> Having said that, I have a feature request that I would be grateful if
> it can be added before the final 3.0 release.  I have read other
> people's requests and your responses about adding another method to
> enable conversion from an InputStream to an OutputStream.  You
> mentioned that the reason the method was removed in the latest release
> was because it used temporary files internally, so there's no
> performance gained.  I still don't get as to why temporary files have
> to be used when you already have the contents in a stream object?  Is
> this a restriction of the OpenOffice service?  Having the "convert
> (InputStream source, OutputStream dest)" method would be helpful as it
> avoids hitting the disk again when the contents of the file is already
> stored in the memory.  This is especially important for applications
> that need to convert hundreds of documents and performance is of
> critical issue.
>

Annoyingly, the search functionality on Google Groups is half-broken
and only returns recent results so old discussions where I explained
this in more detail don't show up.

The point is that the input document data - either stream or file -
needs to be passed from Java to OOo, which does the actual conversion.
Passing it as a file is simple: Java passes the file path as a string
to OOo, and OOo reads the file. That's what we use.

Passing it as a stream is not so simple: you need to wrap your stream
into something that implements the XSeekable interface

http://api.openoffice.org/docs/common/ref/com/sun/star/io/XSeekable.html

in order to pass it to OOo, and that's more like a RandomAccessFile in
Java than just an InputStream - notice the seek() method. So the only
way I could find to implement XSeekable was to buffer the entire file
in memory before passing it to OOo, which of course is not ideal if
the file is huge.

Additionally, passing data in a stream to OOo is slower than just
passing a path and letting OOo read the file.

For this reasons, even if you have a stream in Java, it's
simpler/better/faster to just save it to a temporary file, and pass
the file path to OOo.

Kind regards

Mirko

[Hansen Candrawinata]

On Tue, Nov 24, 2009 at 11:22 PM, Mirko Nasato <mirko....@gmail.com> wrote:

I know, but labels are always somewhat arbitrary. The license says the
software comes with "abolutely no warranties", whether it's labeled
"beta" or "final". ;-)

JODConverter 3.0 currently being "beta" doesn't mean that it doesn't
work, it just means that the API is still incomplete and could change.
In fact, it works well enough for my current projects, converting
thousands of documents a day.

So it's basically in a state where "it works for me", but it can't be
declared stable "for the general public" in terms of API,
documentation, etc. And, from a business point of view, working on
making it more suitable for the general public is a cost that doesn't
give me any returns, which is why it's not a priority for me.

Fair enough :-)

I really appreciate your taking the time to develop and bring JODConverter to where it is now.  I was not trying to complain or anything along that line.  JODConverter has been a very useful tool for me.

I wish I could have the luxury of time to contribute something in return.  I would love to help the development if I could but free time has been pretty tight lately.
 

Annoyingly, the search functionality on Google Groups is half-broken
and only returns recent results so old discussions where I explained
this in more detail don't show up.

The point is that the input document data - either stream or file -
needs to be passed from Java to OOo, which does the actual conversion.
Passing it as a file is simple: Java passes the file path as a string
to OOo, and OOo reads the file. That's what we use.

Passing it as a stream is not so simple: you need to wrap your stream
into something that implements the XSeekable interface

 http://api.openoffice.org/docs/common/ref/com/sun/star/io/XSeekable.html

in order to pass it to OOo, and that's more like a RandomAccessFile in
Java than just an InputStream - notice the seek() method. So the only
way I could find to implement XSeekable was to buffer the entire file
in memory before passing it to OOo, which of course is not ideal if
the file is huge.

Additionally, passing data in a stream to OOo is slower than just
passing a path and letting OOo read the file.

For this reasons, even if you have a stream in Java, it's
simpler/better/faster to just save it to a temporary file, and pass
the file path to OOo.

Thanks for the explanation.  I was not familiar enough with the OpenOffice API and how it does the conversion and what restrictions that it has.  It sounds like using temporary files is still the best way to go.

Thanks,
Hansen