Abstracting away glib?

[Miguel De Icaza]

Hello,

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

Miguel.