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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ariya,

Ariya Hidayat wrote:
> The libwpg main parsing API will consist of the following three:
> - parse from an input stream
This has never been controversial anyway
> - 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.
> - parse from memory buffer
Yeah, this is already done.

> 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.

> Since we desperately need a release (otherwise, more and more projects
> will have a copy of libwpd in their own tree [2]), I reckon if I
> finish implementing and testing support for raster image, we could
> call it a 0.1. It won't be perfect (no pun intended). In addition, the

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

> next version likely would break the binary compatibility because IMHO
> it's difficult to keep it as long as we want to add features (text
> support comes into mind). The API in 0.1 will not be stable anyway, we
> still don't know what others want and/or what we could squeeze more
> from the WPG format.

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.

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

> So if this stream library is not available rather soon, and since
> libwpg 0.2 is going to break some things anyway, let's just make
> libwpg 0.1 very simple: no public API for stream code. The users (or
> rather, developers) that want to use libwpg must use one of three
> parsing functions above. But s/he would not get all the fancy stuff
> like WPGFileStream at his/her disposal, it's internal stuff only.

Why not? If they want to use it, it can be at their disposal. 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...

> Designated result for 0.1:
> - no dependency on libwpd, we'll have a local copy of the abstract
> WPXInputStream

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.

> - no public class of any stream implementations
> - building is (hopefully) very easy on Win32

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.

> Then in libwpg 0.2 we start to introduce the *dependency* to your
> stream library. This won't change the API at all (w.r.t to parsing),
> except:
> - we won't have any WPXInputStream anymore, we depend on what abstract
> class the stream library provides
> - applications (e.g. Abiword, Karbon, etc) depend on the stream
> library include file only, but they don't have to link

Here we agree completely :-)

Fridrich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGVaOPu9a1imXPdA8RAop9AJwJhfFUsScQoFdpoWeMwqKfch5TVwCfV08f
/5HBUHbv2gTjSaj8py5V8EQ=
=wmPT
-----END PGP SIGNATURE-----