Ticket #1829 (closed task: wontfix)

Opened 11 years ago

Last modified 9 years ago

Support of optional mvfs library

Reported by: slavazanko Owned by: metux
Priority: minor Milestone:
Component: mc-vfs Version:
Keywords: Cc: metux,
Blocked By: Blocking:
Branch state: Votes for changeset:


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.

Change History

comment:1 Changed 11 years ago by slavazanko

  • Blocking 1775 added

comment:1 Changed 11 years ago by slavazanko

  • Owner set to metux
  • Status changed from new to assigned
  • Blocking 1775 removed

comment:2 Changed 11 years ago by metux

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

comment:3 Changed 11 years ago by 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);


typedef enum {

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.

comment:4 Changed 9 years ago by andrew_b

  • Status changed from assigned to testing
  • Resolution set to wontfix

comment:5 Changed 9 years ago by andrew_b

  • Status changed from testing to closed
  • Version 4.7.0-pre4 deleted
  • Milestone 4.8 deleted
Note: See TracTickets for help on using tickets.