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

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

Fridrich, regarding the stream stuff, I hope we agree on the following:

The libwpg main parsing API will consist of the following three:
- parse from an input stream
- parse from a file
- parse from memory buffer

They are of the same importance, the last two are provided only for
convenience (useful for developers who won't deal with stream
concept).

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.

Now, on to the pragmatic thing. When are you going to spin off the
stream code and put it in a separate library ? [1] If this is not
going to happen soon, then I propose the following.

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

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 [3].
This is just fine because Abiword uses its own stream code to hook
into the parse function, so does OpenOffice.org. For others (Karbon,
Inkscape), they can choose to parse from file and/or from memory
buffer.

Designated result for 0.1:
- no dependency on libwpd, we'll have a local copy of the abstract
WPXInputStream
- no public class of any stream implementations
- building is (hopefully) very easy 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

Comments? Flames? Ideas?


--

[1] Consider using Google project hosting rather than SF. Google's
infrastructure is simply faster, better, and uncluttered.
[2] And personally, I don't like KOffice 2.0 (alpha1 to be scheduled
in June) to have a local copy of libwpg at all
[3] Perhaps "stream internalization" that you don't like, but this is
temporary until the stream library is ready