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

[Ariya H. <ari...@gm...>]

> > - parse from a file
> Nah, let's leave this one out, the following buffer should be enough as
> you proposed, people can read the file into memory and then use the
> buffer stuff. What we really do not want is to bloat the core libwpg
> with a lot of stream code.

OK. I'm fine if we drop this one.

> > Also, we agree that there should not be any stream implementation
> > inside libwpg. Thus, no more libwpg-stream stuff. All related stream
> > code will be placed in a separate library, which hopefully someday
> > projects like libwpd/libwps/libwhatever will (re)use. Thus, we share
> > more code and simplify matters.
>
> I don't think that I agree with this wording exactly. I would still
> leave the separation of libwpg-stream and libwpg, it would nevertheless
> be not necessary to have the libwpg-stream or even the WPXStream.h
> header to build against the libwpd.so. I committed something in this sense.

Here I was referring to the future "ideal" case (e.g. libwpg 0.2),
where you already build the separate stream library (which will be a
dependency for libwpg, perhaps also libwpd and libwps). I'm sure we
don't want to duplicate all that stream code again in libwpg
internally.

> Yeah, I would still be happy if the wpg2svg was able to create a SVG
> with embedded rasters in it (using the data uri)...

I'm working on that. Normally we need libpng to generate the highly
compressed PNG output, but let me try with my quick-and-dirty
non-compressed PNG generator. I'd like also to keep the dependency
minimum.

> I agree that we should release ASAP. Why not to go with this option:
> let us release what we have with the libwpg-stream.so and libwpg.so
> separation. It is anyway purely semantical one since it is basically the
> same whether you link against one bloated library or two smaller ones,
> with the additional benefit of having the possibility to disregard the
> stream one whenever it is not needed.

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.

Granted, perhaps the application developer only needs to do simple
search-and-replace when switching from libwpg 0.1 to 0.2, but still
that's extra work.

> I really really do not like the stream internalization :-(

I know. But what I proposed is not stream internalization per se,
because there won't be any stream code inside libwpg.

> Why not? If they want to use it, it can be at their disposal.

See the above.

Side note: I'm fine if for now (version 0.1) there is no direct
support for OLE stream because Abiword uses its own stream hook (to
libgsf) and OpenOffice.org IIRC uses also its own stream code. For
others (i.e only Inkscape now), well, it's not that there is a ton of
OLE-ed WPG clip arts. And still, they can wait for 0.2.

> Concerning the stream library, I am awaiting input in terms of feature-requests. I
> think, the WPSStreamImplementation stuff can be very well put into a
> library. But there was an idea of doing an output stream interface too...

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.

> This dependency is really really not a problem. Koffice already uses
> libwpd. And there is hardly any linux distro that does not have
> libwpd-0.8.x.
> If Inkscape takes a precompiled win32 binaries that we provide and uses
> the buffer approach, it will simply have no problem with any
> dependencies at all, since the WPXInputStream class is forward declared
> in the header and the buffer function will not have it in their signature.

Fair enough.

Note 1: do we still need libwpd_types.h?
Note 2: how about building on Mac OS X? any attempt yet?

> It is brain-dead easy now already, I spent some time on it to make it
> so. And that is a sacrifice, because I really hate developing on win32.

Good points. I have mingw now so I'm going to give it a try.
I know how terrible it is to hack on Win32, so thank you for that work!


Regards,

Ariya


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.