Re: libgsf: very preliminary patch

I will look at this more later, and give you a more lengthy opinion, but
just putting this out there:

The new WV requires glib on Win32, and I'm fairly certain I also need to
build libgsf for that as well. So for me, recent glib and libgsf in the
main Win32 dist. for 2.6 is a done deal: it's necessary already.

If we can use the dependencies brought in for wv 1.2.0 to improve the
rest of the abi code base (effectively increasing our use of the
dependencies), I feel that this would further justify their already
necessary inclusion, so I (as of right now) am in favor of that.

Additional side effect of 2.6: dep downloading in plugins (except maybe
for equation editor) will go away since it will all be in the base
installer.

Until after this exam,
Ryan

Dom Lachowicz wrote:

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

-- 
Ryan Pavlik
AbiWord Win32 Platform Maintainer
www.abisource.com
"Optimism is the father that leads to achievement." - Helen Keller