From: Jody Goldberg (jody@gnome.org)
Date: Mon Oct 27 2003 - 15:41:43 EST
On Mon, Oct 27, 2003 at 08:55:28PM +0100, Jordi Mas wrote:
> It will be cool to have a detailed list of which things exactly libgsf is
> supposed to abstract.
There are 4 key interfaces, a number of useful implementations of
those interfaces and some common utility code.
- Interfaces
GsfInput / GsfOutput : basic read/write descriptors
GsfInfile / GsfOutfile : compound files
The interfaces are intentionally minimal, and provide little more
than a 'name' of some sort for errors, read/write/seek/tell. Too
large an interface is impossible to maintain across a large set of
distinct stream types. The interfaces are tuned for our types
of applications, with fine control over how to buffer reads.
- Supplied implementations
: zip, bzip2 : sure these are already available in they're own
libraries (which we depend on) but supporting each is lets say
100 lines of code per instance.
with gsf you can write
GsfInput *maybe_gunzip (GsfInput *input)
{
GsfInput *gzip = GSF_INPUT (gsf_input_gzip_new (input, NULL));
if (gzip) {
g_object_unref (input);
return gzip;
}
return input;
}
And trivially support transparent gunzip for all formats.
: Mem buffer. Again, this is not rocket science, but having the
same interface as mmap/stdio removes this from the path of the
import author. Gnumeric wrote a zip based parsed for OO files.
Then immediately managed to support clipboard content from OO.
- Utility code
: by having a decent set of libxml2 SAX wrapers it becomes easy
to write fast, maintainable sax based parsers.
: I'm going to push over a nice sax based xml file type
recognition routine shortly.
> <in my opinion>
>
> In some cases, the best way of archiving this goal may be to follow the
> Abiword model, that is, XP + platform indepedent code. For example, you
> define an API that you need to use Internet related protocols. Under Unix
> it can be just a wrapper over libcurl, in win32 just a wrapper over
> wininet, and so on other platforms.
>
> </in my opinion>
This is exactly what libgsf is. The only differences between libgsf
and the code in abi xp_* land is that gsf uses glib, and projects
other than abi can use the results.
- Does glib add a dependency. Yes. However, you've already got a
stripped down copy of it in libole2 and a libgsf depend in libwv.
There are other large projects on win32 that depend on it (gimp).
- Will depending on glib 'bloat' abiword. I suspect that at the end
of the day the increase will not be large given the amount of crud
and duplication that will get removed as a result.
- Is glib going to turn abiword into OO. No way in hell. Its a
small actively maintained library. Not one of the three copies of
escher parsing in OO.
Folks this has everything to do with platform. As things stand
Gnumeric and Abi are each forced to write the high level application
code necessary to support large scale office apps. That is a huge
drain on resources. At some level our needs are very very similar
and I doubt anyone will argue that there are no benefits to sharing
code. Gnumeric has almost exactly the same goals as abiword (with
s/wordprocessor/spreadsheet/ of course). We need similar sorts of
widgets, and want to run on similar platforms.
Lets work together on this.
This archive was generated by hypermail 2.1.4 : Mon Oct 27 2003 - 15:43:06 EST