From: Dom Lachowicz (domlachowicz@yahoo.com)
Date: Sun Oct 26 2003 - 18:31:35 EST
> Ignoring my bias against glib/etc on Windows, please
> do this
> in Head, I don't think my mind can handle another
> branch and
> if we are going to add this set of dependencies,
> then I want
> to go ahead and work on cleaning out/up* duplicated
> work
> (xml parser, iconv, ut_*, ...); switch the Windows
> build
> over to enchant, and alter the glib/gsf based
> plugins to
> no longer include glib/gsf/etc. (I'll try to commit
> their
> installer later today, after I get a chance to
> check/fix
> any build issues on Windows with them.) Also, are
> we going to
> build glib/gsf like we build the rest of our
> libraries or are they
> going to be binary additions to our build process?
> Does
> a Win32 developer need to talk with the Gimp for
> Win32 folks
> so we can share their glib implementation and
> coordinate any
> fixes necessary with them? Are we going to use
> their binaries?
> or just their source? is their glib/gtk/etc source
> the same as
> the Unix based one?
Well, there are some concrete reasons why I want to do
this in another tree, at least for the moment:
1) I'm not happy with my initial work. I need a lot of
latitude to play with it.
2) I don't want to commit something that affects just
a few importers or exporters. I want all of HEAD to
use it or none of it.
3) Getting build systems in place and answering the
"are we going to use their binaries" type of
questions.
4) I'd like to not have the impression that I'm
forcing something down people's throats. At least not
at this point in time.
So, I'll do the work in my own tree. If you don't want
to set up a build system until it's merged back into
HEAD, that's entirely acceptable to me.
Despite Mike's pessimism, it's entirely possible that
the HEAD version of Abi might not use GSF (much to my
chagrin), should someone make a plausible argument
against it. To date, no one has stood up to make a
coherent argument against it on-list. Off-colour
gripes on IRC don't count. If you'd rather argue that
I should make the case for using it, please ask me to
do so, and I'll gladly extoll its virtues. Quite
likely, I'll talk your ear off :)
There are some direct implications of this changeover
that could greatly benefit the win32 folks too. GSF
will probably soon have a libcurl backend - so the
win32 port will also be able to read remote files. GSF
also has a half-working implementation of IStream and
ADODB::Stream, meaning that Abi could easily
communicate with most COM components or that Abi could
be a COM component talking to the outside world. It
also means that Abi could act upon things like BLOBs
inside of databases. Abi could easily be part of OLE
or backoffice automation projects. Abi could be
invoked from ASP scripts running on IIS servers, and
then persisted to a database. And I think that is
immensely cool.
But yes, I'd also like to remove a lot of the
duplicated stuff in UT_ that has direct glib
equivalents, such as our libiconv dependency and any
treading stuff.
I'm not intentionally trying to force anything down
people's throats. I think I'm acting in a way that
will best serve Abi's future on all of our platforms.
Best regards,
Dom
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
This archive was generated by hypermail 2.1.4 : Sun Oct 26 2003 - 18:32:40 EST