Re: [Libwpg-devel] Proposal: input stream simplification

[Fridrich S. <fri...@bl...>]

Ariya,

Ariya Hidayat wrote:
> Because one good reason (IMHO): this libwpg-stream will soon disappear
> tentatively for libwpg 0.2 (because by then we need your stream
> library). There is no point offering some code which won't be
> supported at all in the next version, nevermind that the stuff in
> libwpg-stream has no direct relation to WPG format.

I am turning this since two weeks in my head, and really understand your 
concerns. On my side, I would like to have the wpg2foo tools support 
also the OLE2 embedded documents. Believe me, the wpg importer 
integrated into stock OOo is not for tomorrow because there is a lot of 
bureaucracy about including new libraries (libwps approval by Sun legal 
took 6 months and I was bugging the people litterally every day) and new 
features. And the add-on converter built against the SDK is using those 
stream classes. And I cannot change it, because all the resources that I 
use for the integrated filter stream class are not exported in the 
public API :-(

There would be possibility to remove the stream abstraction in libwpg 
and keep the OLE2 stuff in wpg2foo tools: make them depend on 
libwpd-stream-0.8 and make them use the GSFStream class. That is the 
stream class that is there for whole 0.8.x release series, but this 
would mean a gsf dependency and I really feel uneasy about it.

So, if you could make me a favour and live with this situation, I would 
really prefer to have in the libwpg sources a WPXInputStream 
implementation that supports OLE2 embedded WPG files. It is really dead 
easy to build and link with. The statical perfectspot.exe is the witness.

> For output, perhaps:
> - stream to file
> - temporary file ("scratch")
> - zip container 
> Would be fantastic if we can create ODF container using this library
> (useful for stand-alone command-line tools, not for e.g.
> OpenOffice.org filter)
> As I wrote earlier, seems we're going to create the more-portable, C++
> version of libgsf.

Honestly, when I am turning this in my head, let us start with the input 
stream class and not to focus on big constructions. An approach of 1 
interface class + 1 sample fully functional implementation (with as 
little dependencies as possible) would be a good start. I do not think 
that I will have enough free time (and surely not the official blessing 
of my employer to do it in company time) to replace libgsf :-(

> Note 1: do we still need libwpd_types.h?

Kind of. it is because of the uint8_t * output of the read function. 
Since the return values are not part of a function signature, an 
unsigned char * could work as well. But again, this would mean to 
require a very recent version of libwpd for the WPXStream.h header 
without libwpd_types.h (which is really little). I am also thinking 
about removing the use of uintXY_t and intXY_t from libwpd for next 
release cycle (as we do not use it in libwpg), nevertheless, given that 
I spent >a month auditing libwpd code for different potential integer 
issues, I really don't want to do this very quickly, because having an 
advisory agains your library is quite tiring stuff, especially if many 
many many people use it.

> Note 2: how about building on Mac OS X? any attempt yet?

Not yet, sorry

> PS: I'm not adamant to get rid of libwpg-stream. I know you must have
> a very good reason to do this separation. Just please consider my
> rationale above. I have no problem if we decide not to drop it, I just
> want to make sure we all know the consequences.

I would really really like to keep it there for 0.1.x and drop it for 
0.2.x. Can you live with my stubborneness?

Cheers

Fridrich