Re: Abstracting away glib?

[Enrico Weigelt <weigelt metux de>]

* Mourad De Clerck <mourad aquazul com> schrieb:

Hi,

> 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

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

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

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

For what ? Where exactly is the benefit ? 

> these; stuff like GIO/GVFS, 

No, please not. GVFS is yet another fat blob, and even worse: it runs
everything over dbus. (dbus itself - IMHO - is an really stupid invention 
for things where an simple fs protocol like 9P would fit much better).

We're currently in process of moving to libmvfs step by step, there's
already a branch waiting for commit, which adds several libmvfs-based
fs'es, like 9P. Once all of mc's own fs'es have been ported to libmvfs,
we can replace mcvfs by libmvfs.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------