-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Enrico Weigelt wrote:
> ACK. But we also should have the traditional one built-in > as a compile-time option (for small systems). Small systems? In this case better way to use present libraries as possible for lesser size binary file and for less memory usage per one process. Code of libraries will shared in memory between processes rather than have same blob-code in any running process. And in reply to http://www.midnight-commander.org/ticket/1784#comment:12 >>> It is *MUCH* smaller, similar in size like mc's internal vfs. >> And this all reasons? > To me, it definitivly does. To me not. In really small systems better to use busybox without mc. Or just older versions of mc... > I dont want the whole gnome blobs on dozens of small devices, VZs, etc just for mc. This is not a reason for drop external libraries from mc. Is you want big binary blobs of? In any case, for VZs you may use command: mount -obind /opt/VZ_environ/lib /home/some_user/vz/lib. About in-memory usage I'm already described. >> What about 'powerfull' >What kind of power do you need from an VFS layer ? What's missing eg. in current mc's one ? WEBDAV; CURL; DeviceKit support; good realization of files/dirs change notification support etc. >> 'well supported', > What kind of support do you need ? Good documentation for library, own bug tracking system, own devel-team. Glib (and gio) good candidate for this. No need to maintain any (builtin) libraries with mc (exclude in future libmc.so for better implementation of plugins). > What kind of scalability do you need ? In which direction should a VFS API scale ? Partially yes. Own realization of ini-files parser was good realization too (was grabbed some time ago from wine project). But why we need to maintain this code? Glib have realization (desktop.org compatible): http://library.gnome.org/devel/glib/stable/glib-Key-value-file-parser.html We just was remove own ini-parser. Same case about own libpopt realization - glib have command line parser (standart for all glib-based applications) and we just use it instead of own _deprecated_ code. Why we need for own VFS layer? > libgio is full of things we most likely won't ever need. How do you know this? P.S. About libmvfs: Is someone something known about this library (exclude Enrico :) )? WBR, Slavaz. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFK8T/cb3oGR6aVLpoRAvGKAJ4lXsSc/OpLBbu6YQydvxNERik4wACfUEUW BmIetDIwNcGVIwqY37Z6yCE= =o75f -----END PGP SIGNATURE----- _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel