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

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

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

Hi Ariya,

First of all, thanks a lot for the nice work on perfectspot. It was  a
great experience to see commits raining into the CVS.

Now, concerning the stream implementations, I really hate to look like
an enemy of progress, but I have to expose my take on it:

1. The reason why I made libwpg to use the WPXInputStream interface was
that sometimes in a next feature, I would like to branch libwpd and add
some possibility of parsing embedded pictures. This would just allow me
to extract the subdocument as a WPXMemoryInput stream and pass the
pointer to libwpg and grab whatever it outputs and process internally.

2. The other reason is that three libraries actually use something that
could be really really the same thing: libwps uses WPSInputStream that
is derived from WPXInputStream. I made the libwpg use the WPXInputStream
also for maintenance reasons. In the future, I would like to have only
one WPXInputStream implementation library for free use, so that I do not
have to commit the same change into 2 different cvs repositories and one
svn too :-). To have the stream the same in all three made it very very
simply for me to integrate the wpg importer into ooo-build some two
weeks ago and allowed me to reuse in a considerable way the
writerperfect infrastructure.

3. To keep the stream abstract showed itself a very good solution with
libwpd and allowed us to have a stable libwpd API and ABI for more then
2 years already. I really would like to have the library itself free of
the stream implementation if it was possible.

4. The dependency of libwpd is true, but it is actually a dependency on
one only header file <libwpd/WPXStream.h>. I have to fiddle more with
the build system, because libwpd should not be necessary for the binary
libwpd and libwpg-stream, neither should it be necessary for linking the
libwpg and libwpg-stream. For applications that use libwpg and do not
use libwpd (very few of them actually), putting the WPXStream.h header
somewhere should be enough.

5. The convenience functions can be achieved this way:

parseFile(filename, &exporter) -> parse(&WPGFileStream(filename),
&exporter);

parseBuffer(buffer, length, &exporter) -> parse(&WPGMemoryStream(buffer,
length), &exporter);

Since the temporary as a parameter of the function should survive during
the life of the function, right?

This is my take, and as I already said, I hate to be an enemy of
progress :-( Nevertheless, the stream internalization does not look like
a good idea for me at this stage.

Cheers

Fridrich

P.S.: Ariya, I really like your work and have a high esteem of your
coding capacities (as opposed to mine). I was turning this stream issue
in my head since before the start of last year's GSoC, and have really
impression that abstracting the stream is a good solution.

Ariya Hidayat wrote:
> Hi folks,
> 
> After giving some though about input stream handling, here is my
> proposal to simplify the implementation. The objectives:
> 
> - make it very easy for developer that just wants to parse from file
> or memory buffer
> - make it possible for developer who has its own input stream implementation
> 
> The first applies to the use case to create WPG to Foo converter, e.g.
> our very own command-line converter wpg2odg. In this case, wpg2odg
> does the following:
> 
> 		OdgExporter exporter(&tmpHandler);
> 		libwpg::WPGraphics::parse(input, &exporter);
> 
> where input is an instance of FileStream (or MemoryStream, if it would
> have loaded the content first to memory), which I think could be
> simplified as:
> 
> 		OdgExporter exporter(&tmpHandler);
> 		libwpg::WPGraphics::parseFile(filename, &exporter);
> 
> or
> 
> 		OdgExporter exporter(&tmpHandler);
> 		libwpg::WPGraphics::parseBuffer(buffer, length, &exporter);
> 
> where filename specifies the filename and buffer+length specifiy the
> memory buffer.
> 
> Of course, the standard WPGraphics::parse can be still useful,
> especially for the second use case: applications which have its own
> stream handling.
> 
> In particular, for example if the next version of libwpd would support
> embedded picture in WP document, then it needs to depend to libwpg and
> should allow the listener to "capture" WPG events. However, WP
> graphics are different than WP documents. It is unlikely that the size
> of the graphics would reach e.g. 10 MB or larger. Thus, input class
> which really "streams" the data might not be needed. In short, libwpd
> can just read and load the whole picture data first, then use the
> WPGraphics::parseBuffer() above.
> 
> To clarify, here are the steps that I would like to undertake (if we
> agree on this):
> 
> (1) Integrate the stream code completely into the main parsing code.
> Thus, there is no libwpg-stream module anymore and libwpg won't depend
> on libwpd anymore.
> 
> (2) Create parseFile() and parseBuffer() convenient functions, they
> create the necessary file stream and memory stream and then call the
> standard parse() function. Thus, for those who just want to parse from
> file/memory, no need to deal with stream concept.
> 
> (3) Only make WPGInputStream public, the other stream classes
> (WPGMemoryStream/FileStream/OLEStream) are internal only because they
> are unlikely useful for others, e.g. libwpd has its own, as does OO.o.
> 
> The implications:
> 
> * there is only libwpg shared library, no more libwpg-stream
> * libwpd does not depend on any other library, including libwpd
> * filter code in OO.o/Karbon/Inkscape typically uses either
> parseFile() or parseBuffer() function
> * parse() is offered only for those who really really absolutely wants
> to handle the input stream by itself
> 
> Comments? Objections? Ideas?
> 
> 
> Regards,
> 
> Ariya
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Libwpg-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libwpg-devel

- --
Please avoid sending me Word, Excel or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGUFHgu9a1imXPdA8RAt5GAJ96zFCSP997n/T1vR5Is4kLGiJ/4QCeNCtc
RBSzr48mHOcPsqs/RDgsiZo=
=7HGo
-----END PGP SIGNATURE-----