* Slava Zanko <slavaza...@gmail.com> schrieb: Hi,
> 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. Assuming they're present at all. For lots of my systems, mc is currently the *only* app requiring glib, adding 868k. If libgio will come in, this will even extend to 99% of all my systems, adding 690k. > To me not. In really small systems better to use busybox without mc. Or > just older versions of mc... What a great suggestion ;-o > > 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. No, but it's a reason for not adding more fat ones including their dependencies. > 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. Assuming, that sharing is possible at all (host *and* vz nodes are all under the same administration). > >What kind of power do you need from an VFS layer ? What's missing eg. > >in current mc's one ? > > WEBDAV; CURL; DeviceKit A matter of proper fileservers. (plan9 folks already have ones for http, webdav, ftp, ...) > support; good realization of files/dirs change notification support etc. Besides local linux (inotify), there's little chance to get it working w/o cyclic reloading. > No need to maintain any (builtin) libraries with mc (exclude in future > libmc.so for better implementation of plugins). 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). Aehm, what does an ini parser have to do w/ a VFS API ? > Why we need for own VFS layer? > > > libgio is full of things we most likely won't ever need. > > How do you know this? Does MC need the "streaming" stuff (which is just yet another wrapper around standard filesystem operations) ? Does MC need desktop icon stuff (render them in ascii ? ;-o) Does MC need yet another socket API (besides OS/libc) ? Does MC need yet another DNS resolver ? etc, etc, etc Note: I'm talking about whats really needed for a good _console_ file manager, not what could be done if certain people have too much tedium and dont care about loosing large parts of the traditional user base ;-o 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