Presentando SVFS

[Rogof]

El año pasado me encontré programando algo que requería un Sistema de Archivos Virtual (VFS). El programa principal interpretaba scripts escritos por el usuario, en los cuales el usuario podía manipular tanto elementos visuales (botones, etiquetas, etc.) como archivos (música, imágenes, etc.). Estos archivos eran especificados por el usuario, por lo cual el VFS se encargaba de abstraer esto.

Al final me encontré usando un programa ya existente, pero desarrollando el VFS, el cual llame SVFS  (Simple Virtual FileSystem) -a falta de imaginación-, me encontré con conceptos que me parecieron interesantes, así que aquí los comparto:

SVFS es una biblioteca -en desarrollo-, el prototipo está escrito en C++. La  raison d'etre de esta biblioteca es que requería un VFS mutiplataforma, y que no me pude aguantar las ganas de implementar estas ideas.

El desarrollo de SVFS esta influenciado por los sistemas de archivos de Linux/BSD, FUSE, KDE KIO_SLAVES y otras implementaciones de VFS. SVFS toma prestadas varias de estas ideas y la mezcla ha resultado en lo que sería una biblioteca ligera, modular y multiplataforma.

La idea es que SVFS es sólo una colección de VNodes (nodos virtuales). El VNode es la interfaz mediante la cual se accesa a un recurso (explicado más adelante). El manejo a bajo nivel de recursos se efectúa por medio de slaves.

En esta implementación, SVFS es una coleccioné de VNodeInit, los cuales contienes información acerca de como obtener el recurso, y los VNodes son creados dinámicamente y puestos en un cache, para evitar gastos innecesarios de recursos.

SVFS nos permite directamente mover y eliminar VNodes, pero no crearlos. Por raro que parezca, esto es a propósito, los VNodes (y VNodeInits) son creados por los plugins, lo cual permite a SVFS ignorar a qué están ligados los VNodes y aun así funcionar.

He aquí una de las cosas que lo hacen flexible, los VNodes (y para el caso los recursos) pueden ser cualquier cosa que nos provean los plugins. Esto significa que los recursos pueden ser archivos locales o remotos, e incluso puede que no sean archivos.

Para que SVFS nos sirva de algo, primero necesitamos agregar Souces (fuentes) en las cuales se encuentran los recursos. Yo he optado por especificar las fuentes en forma de URI, ya que este es agnóstico al sistema operativo. D

La forma de interacción con los recursos dependen de la implementación del plugin.

Ahora, los plugins nos pueden proveer de dos cosas:

•  Slaves (nombre tentativo): Estos se encargan de crear los VNodes, cada Slave esta relacionado a un Scheme.

•  VNodeType: Este contiene la forma especifica de como se interacciona con el recurso.

Cada Plugin puede registrar más de uno de cada cosa, así un plugin puede responder a los schemes http y https.

Aquí tenemos un ejemplo de cómo se podría utilizar:

SVFS svfs;

/* agregar fuentes por URL */

svfs.AddSource( "file:///home/user/lol.png" );

svfs.AddSource( "file:///home/user/cat.png", "/img" );       // especificando el "punto de montage"

svfs.AddSource( "http://www.example.com/bear.jpg" );   // imagen en internet

svfs.AddSource( "tar://home/user/tarfile.tar.gz" );              // cada archivo en el tar es un VNode

/* los siguientes ejemplos utilizan URN, en lugar de URL */

svfs.AddSource( "system:cpu:0" );                       // estatus/info del core 0 del cpu de la máquina

svfs.AddSource( "system:mem" );                        // estatus/info de la memoria de la máquina

...

/* así se usaría */

file = svfs["/lol.png"];              // o svfs.get( "/lol.png" ) 

file = svfs["/img/cat.png"];

file = svfs["/system/cpu/0"];

file = svfs["/system/mem"];

/* en el caso del archivo tar, asumiendo que este contiene a file1.txt y file2.txt */

file = svfs["/tarfile/file2.txt"];

std::cout << file.read() << std::endl;

Por ultimo, esto es una idea medio desarrollada, me gustaría saber que opinan y si les interesa.

[Vendaval]

Es una excelente idea. Me imagina que estas programando cosas muy chidas.

Tiene muchas aplicaciones, me parece que mantener el método get (Es mas elegante) de SVFS es mejor para tu código. 

Agrega la pagina del proyecto para poderle echar un ojo a los detalles. 

Saludos, me da gusto saber de ti.

--
Has recibido este mensaje porque estás suscrito al grupo "luguam" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a lug...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a luguam+un...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/luguam?hl=es.

--
"No estoy de acuerdo con lo que dices, pero daría mi vida por defender tu derecho a decirlo"
^^Voltaire^^

[Rogof]

Por el momento no hay pagina para el proyecto, debido a que parte de la
razón de tal fue para familiarizarme más con cmake, doxygen y git, así
como para refrescar y expandir mi conocimiento en C++ (el cual no es
mucho, así que no esperen la gran cosa).

En su momento agregare el proyecto a github y les dare el link, pero
primero necesito limpiarlo (mover de lugar scripts de cmake y cosas
por el estilo) y hacer que compile por lo menos en mi máquina ya que un
cambio en una de las dependencias más el cambio a gcc 4.6 rompio el
programa (el código en cuestion tiene más de 4 meses de antigüedad)

[Rogof]

Al parecer, la ultima vez que toque el proyecto lo deje en un estado inestable (no recuerdo qué es lo queria hacer), debido a esto, me estoy tardando más de lo esperado en limpiar el proyecto...

Dejando eso a un lado, lo que he terminado de limpiar es el PluginFramework, el cual utiliza SVFS para cargar los Slaves. Esta biblioteca es una modificación del Framework que se expone aquí <http://drdobbs.com/cpp/204202899>.  El API casi no ha cambiado, asi que los ejeplos que ponen ahí  deberian de funcionar sin mayores cambios.

He adjuntado el código fuente por si quieren jugar con el. Para compilar necesitaran boost >= 1.45.0 y cmake >= 2.8 El programa compila con gcc 4.6, clang 2.9 y mingw32-gcc 4.5.

Deberia de poder compilarse en cualquier plataforma el la que las bibliotecas de boost esten disponibles.

Compilando:

$ ls -a
. .. plugin_framework.tbz2
$ mkdir pluginframework
$ cd pluginframework
$ tar xf ../plugin_framework.tbz2
$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.46.0                                        ## o la version que tengas instalada
-- Found the following Boost libraries:
--   filesystem
--   system
-- Using stdint.h
-- Configuring done
-- Generating done
-- Build files have been written to: /home/genericuser/pluginframework
$ make
Scanning dependencies of target dynload
[ 25%] Building CXX object CMakeFiles/dynload.dir/platform/posix/dl_imp.cxx.o
Linking CXX static library libdynload.a
[ 25%] Built target dynload
Scanning dependencies of target elogger
[ 50%] Building CXX object CMakeFiles/elogger.dir/elogger/third_party/libcxxtl_0.1.3/tri_logger.cpp.o
Linking CXX static library libelogger.a
[ 50%] Built target elogger
Scanning dependencies of target pf
[ 75%] Building CXX object CMakeFiles/pf.dir/plugin_manager.cxx.o
[100%] Building CXX object CMakeFiles/pf.dir/dynamic_lib.cxx.o
Linking CXX static library libpf.a
[100%] Built target pf

Como pueden ver, CMake crea por default librerias estaticas. Si quieres generar librerias compartidas agrega -DBUILD_SHARED_LIBS al final del comando cmake

 Sujerencias, reportes de bugs y parches son bien recibidos ;)

[Vendaval]

muy agradecido.

--

Has recibido este mensaje porque estás suscrito al grupo "luguam" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a lug...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a luguam+un...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/luguam?hl=es.

[Rogof]

Ya hace un rato que termine la "limpieza" pero he estado ocupado con otras cosas.

Ahora, me gustaria tomen en cuenta que los lenguajes que generalmente utilizo tienen colector de basura, así que, al no estar acostumbrado a manejar la memoria de forma manual, es bastante probable que tenga varios leaks de memoria. También tomen en cuenta que este es el resultado de sólo 3~4 semanas (contando los descansos y el tiempo de investigación) y que estube agregando componentes conforme los sentia necesarios, por lo que este código esta lejos de la elegancia.

Bien, aparte de lo que necesita el PluginFramework para compilar, este nececista de la biblioteca uriparser, los pasos para compilar son similares excepto que esta ves no se necesita crear una carpeta temporal, solo extrae el archivo y cd a  la carpeta que se creó.

NOTA: SVFS no compila en windows (todavia)

Para aquel que este interesado, el código que me pertenece esta liberado bajo la licencia MIT.

En estos 3~4 meses que han pasado desde que cree svfs, he visto varias cosas interesantes, algunas de las cuales me gustaría integrar.

En corto, lo que me gustaría hacer es:

• Integrar algunas de las ideas de PlugMan al PluginFramework
  
• Cambiar el nombre a PluginFramework (demasiado aburrido)
• Implementar SVFS como plugin para el nuevo PluginFamework
  
• Sacar una version decente de SVFS

Sujerencias en como lograr los puntos anteriores, asi como nuevo nombre para PluginFramework son bienvenidas.