* Mourad De Clerck <mou...@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/ --------------------------------------------------------------------- _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel