Re: libgsf: very preliminary patch

I'd like to talk about libgsf, and see what the
community's consensus is around it.

I've talked about its features previously. Some of
them are useful (abstracting out filesystems, not
overwriting old files unless save succeeds, etc.), but
they're probably not killer features. At least for
non-Unix platforms. Tomas has expressed a desire to
use it because it will help us handle filename
encodings properly on Win32, which has always been a
sore spot for us.

I believe that AbiWord's continued relevance on the
GNOME platform (if it is to have any) requires us to
use this technology. I don't believe that this point
is debatable.

However, its utility on non-Unix platforms is
debatable, especially since it brings new dependencies
like glib and friends.

Now, one could argue in favor of using libgsf
everywhere outright. Some of our more interesting
imp/exp plugins already require it (OpenDoc,
WordPerfect) and our users seem to want those plugins.
The only maintained DOC importer requires it. Etc.

But I can understand wanting to keep ourselves slim
and trim. I don't believe (or perhaps, don't want to
believe) that we can reasonably factor-out libgsf's
functionality into platform-specific interfaces. I
think that if we want to do this, we want to rely on
someone else's platform (even if that someone else is
effectively "gnumeric + dom"), and not roll our own
yet again. This is of course, debatable.

I want this patch set to have the blessing of version
control and etc. that CVS/SVN/etc. gives us. So my
question is - how do we proceed? Should we:

1) Check this into HEAD once it's closer to being
ready. HEAD is already pretty broken. Who will notice
one more thing?
1.a) Or will this be the straw that breaks the camel's
back?
1.b) Requiring the Win32 guys to install glib-devel
and goffice might be harsh, especially since I haven't
split goffice into a goffice-glib and goffice-gtk
library set yet.
2) Create a branch for this?
2.a) Merging back into HEAD is always a pain, and
branches tend to be unmaintained little ghettos.
3) Maintain a patch set publicly somewhere?
3.a) What about maintaining patches to my patches? Do
I setup git/mercurial to manage this?
4) Fork AbiWord?
4.a) Dear $deity, I don't want to do this, unless the
fork becomes the canonical distribution.
5) Something else that I've omitted.

None of this needs to happen immediately. My patch
isn't ready for inclusion into CVS, as it breaks too
many things and is somewhat sloppy. But its day will
come, and I'd like to know what will happen when that
day comes.

Everyone's opinion on the matter is solicited and
valued.

Thanks guys,
Dom

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Received on Mon Feb 20 21:27:42 2006