Re: Abstracting away glib?


a) memory requirements
-> as you probably know glib is being used for a lot of projects, to the
point that it's hard to avoid at all, even on embedded; on platforms
with really constrained memory (easy to OOM) glib is probably not ideal,
but to be honest, I can't imagine running mc on those either;

We're actually using only a *very* small percentage of glib - all we
need easily fits in a bunch of .h files. Glib is just a fat blob which
makes more hassle than it's worth it, IMHO ;-p

Not really; It makes the code cleaner, and it makes the code more maintainable as people that already have experience with glib are able to pick up easily and start contributing effectively from the get-go as opposed to learning a new internal API for basic stuff.

But if memory consumption is that much of a concern to you, you are free to pull the "Embedded GLIB" which is an MIT X11 licensed version of the glib API designed for embedded systems. It is part of Mono's source code.

For a project that does not get a lot of contributors: maintenance always comes first.

b) performance
-> Enrico Weigelt mentioned some ways in which glib is underperforming
or adding unnecessary abstractions. I'd argue that if it's just the
implementation, it should be fixed in glib itself;

In theory you're right. But from my own experience I can tell you that
this won't happen (unless we're doing our own fork ;-o).

Are you guys being serious? A file manager spends most of its time doing file I/O and any glib abstraction over g_malloc or whatever else is negligible.

c) possible interface breaks
-> I think every library has those, but I also think glib has been
better than most in maintaining the compatibility since their last major
API break 7 years ago.

In recent years, I've experienced enough glib trouble (not just interface
breaks) for disliking it, especially when it's not really needed.

Which interface breaks?   That is nonsense.

Glib has been API stable since Gnome 2.0 came out. If you have had problems document them.

I for one doubt your statement very much.

But I'd expected you to start using more of glib, instead of less.

For what ? Where exactly is the benefit ?

Open Source Development 101:

	* Someone else maintains the code
	* Someone else fixes the bugs.
	* We benefit from both.
	* Less work on our plate.
	* Easier for newcomers with previous experience to pick it up.
	* Minimize number of bugs.
	* Reduce maintenance cost.
	* Shared development cost.
	* Shared code in memory with other processes.
	* Improvements in glib, improve mc directly
		(better hashtables, we benefit, better allocation, we benefit).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]