Support of optional mvfs library

[slavazanko]

As part of reworking VFS subsystem we may support of MVFS library ( <homepage to repo/docs must be here> ).

I think, better way for support third-party vfs'es - dynamic load these libraryes via some own wrappers (and register some handler of new vfs in own mc-vfs). In additional will better to make modular architecture with pluggable ability.

In any case, this big task with many thinks.

[metux]

WTF ?!
How many wrappers around wrappers do you want to add ?!

[slavazanko]

Hm... Ok, I'll try to describe some things here (may be in schematical mode).

What I want to see in future:
1) hardcoded code for register VFS-handlers without any other VFS-related code. Just functions for registration of FileSystem? handlers( in separated modules).
1) own hardcoded VFS code no have any VFS-related code. Just functions for register type of FS and handler(module). For example, this will:

mc_vfs_register_handler(const char *type, vfs_reghandler_cb *registrant, void *some_data);
mc_vfs_unregister_handler(const char *type);

Where:

typedef enum {
  MCVFS_ACTION_DLIST;
  MCVFS_ACTION_DCREATE;
  MCVFS_ACTION_DCHANGE;
  MCVFS_ACTION_DREMOVE;
  MCVFS_ACTION_OPEN;
  MCVFS_ACTION_CLOSE;
  MCVFS_ACTION_FATTR;
  MCVFS_ACTION_FMOD;
  MCVFS_ACTION_FWRITE;
  MCVFS_ACTION_FREAD;
  MCVFS_ACTION_FNOTIFY;
  ...
}mcvfs_action_t;

typedef void (*vfs_reghandler_cb) (mcvfs_t *vfs_data, mcvfs_action_t type_of_action <need to thinks>, ...)

2) in some special place (/usr/lib/mc/vfs for example) placed some files (like to: mcvfs-curl.so, mcvfs-extfs.so, mcvfs-gio.so, mcvfs-mvfs.so, mcvfs-fish.so etc). At start mc will read list of these files and will try to dlopen/dlsum (try to plug-in these libs).

3) mc will try to search some standart function into loaded *.so file (dlsym(plugin_handle, "mcvfs_module_init"); for example) and try to run it.

4) Module (or plugin, what more like?) will be self-register into mc core.
For example, function mcvfs_module_init() in mcvfs-curl.so module will make next actions:

  mc_vfs_register_handler("#ftp:", my_mcmodule_curl_ftp_handler, some_data_or_null);
  mc_vfs_register_handler("#dav:", my_mcmodule_curl_webdav_handler, some_data_or_null);
  mc_vfs_register_handler("#ldap:", my_mcmodule_curl_ldap_handler, some_data_or_null);
  ... etc ...

Next example, function mcvfs_module_init() in mcvfs-extfs.so module will make next actions:

 /* open /etc/mc/mc.ext here */
 while (read ('/etc/mc/mc.ext')) {
    some_parced_condition = extfs_parce_one_extention_line_from_config();
    mc_vfs_register_handler(some_parced_condition, extfs_handler, some_data_or_null);
 }

These cases just for example. In this point need to think about standartization of VFS-handlers and <file|filesystem> filter types.

5) all vfs-handlers in modules will handle all types of mcvfs_action_t enum (return NO_IMPLEMENT constant in other case).

6) Need think about conflict situation between handlers (for example, if one '#ftp:' action will handled in 'mcvfs-curl.so', 'mcvfs-ftp.so' and 'mcvfs-mvfs.so' modules. What must have priority?)

With this schema's we will play just with modules (plugins). mc-core don't know about used VFS in plugin: own self-writen VFS, MVFS, GIO/GVFS or other. If plugin exists and if plugin will self-registered into mc-core, then we have support of some filesystems. In opposite, if we don't have plugin, then we don't have support of some filesystems.

In summary, I propose just wrapper for plugins instread of exists hardcoded VFS. In my case, VFS-core will moved into plugins (and in future all plugins code will moved from main repo on m-c.o on plugin repo m-c.o/git.mc-plugins, for example).

Is my idea clean? If anything is unclear - please, ask.