Re: 4.7pre4

[Slava Zanko <slavazanko gmail com>]

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