Re: 4.7pre4

[Enrico Weigelt <weigelt metux de>]

* Slava Zanko <slavazanko 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/
---------------------------------------------------------------------