Cómo funciona JS: almacenamiento

Al diseñar una aplicación web, es extremadamente importante elegir las herramientas adecuadas para el almacenamiento local de datos. Estamos hablando de un mecanismo que le permitirá almacenar información de manera confiable, ayudará a reducir la cantidad de datos transferidos entre el servidor y las partes cliente de la aplicación y, al mismo tiempo, no empeorará la velocidad de reacción de la aplicación a la exposición del usuario. Una estrategia bien pensada para el almacenamiento en caché local de datos es fundamental para el desarrollo de aplicaciones web móviles que pueden funcionar sin una conexión a Internet. Los usuarios modernos se refieren cada vez más a oportunidades como algo familiar y esperado.



Hoy, en la traducción de la parte 16 de una serie de materiales dedicados a todo lo relacionado con JavaScript, hablaremos sobre los mecanismos de almacenamiento de datos del lado del cliente que se pueden usar en el desarrollo web y sobre cómo elegir un sistema de almacenamiento de datos para un proyecto específico.

Modelo de datos

Un modelo de datos define la organización interna de los datos almacenados. Afecta a todos los aspectos del dispositivo de aplicación web, contiene soluciones, a menudo comprometedoras, de las que depende la efectividad de la aplicación y la capacidad del sistema de almacenamiento para resolver sus tareas. No existe un "mejor" enfoque para diseñar modelos de datos, no hay soluciones universales que sean adecuadas para todas las aplicaciones. La elección del modelo de datos se basa en las características y necesidades de una aplicación en particular. Considere varios modelos básicos de almacenamiento de datos entre los que puede elegir algo adecuado para un proyecto en particular.

• Un modelo estructurado de almacenamiento de datos. Cuando se usa este modelo, los datos se almacenan en tablas con campos predefinidos. Este enfoque es típico para los sistemas de gestión de bases de datos basados ​​en SQL. Dichos sistemas están bien adaptados para trabajar con ellos mediante consultas. Un ejemplo bien conocido de un almacén de datos de navegador estructurado es IndexedDB (aunque es un DBMS NoSQL).
  
• Modelo de almacenamiento de clave / valor. Los almacenes de datos organizados en forma de pares clave / valor, y los DBMS NoSQL asociados con ellos, le dan al desarrollador la capacidad de almacenar datos no estructurados y recuperarlos de la tienda mediante sus claves únicas. Tales almacenamientos son similares a las tablas hash en el sentido de que le permiten organizar el acceso a datos indexados de tipos opacos. Un buen ejemplo de un almacenamiento de valores de clave / valor es la API de caché en el navegador y el DBMS del lado del servidor Apache Cassandra.
  
• Un modelo para almacenar datos en secuencias de bytes. Usando este modelo simple, los datos se almacenan como secuencias de bytes de longitud variable. La tarea de organización interna de estos datos se resuelve por completo a nivel de aplicación. Este modelo se utiliza en sistemas de archivos y otros almacenes de datos organizados jerárquicamente, como los sistemas de almacenamiento en la nube.
  

Métodos para el almacenamiento persistente de datos disponibles para el navegador

Los métodos de almacenamiento utilizados en las aplicaciones web se pueden analizar en términos del tiempo de almacenamiento persistente de dichos datos.

• Almacenamiento de datos dentro de la sesión. Los datos de esta categoría se almacenan solo mientras exista una sesión web específica o la pestaña del navegador esté activa. Un ejemplo del mecanismo para almacenar datos de sesión es la API SessionStorage.
  
• Almacenamiento de datos en el dispositivo sin referencia a la duración de la sesión. Estos datos se almacenan en un dispositivo específico y entre sesiones, por ejemplo, cuando cierra la pestaña del navegador con la página de la aplicación web, no se eliminan. Un ejemplo del mecanismo para almacenar datos de aplicaciones web en dispositivos es la API de caché.
  
• Almacenamiento permanente de datos mediante almacenamiento global. Este enfoque implica almacenar datos que no se pierden entre sesiones y no están vinculados a un dispositivo específico. Dichos datos pueden ser compartidos entre varios dispositivos por los usuarios. Como resultado, esta es la forma más confiable y a largo plazo de almacenar datos. Dichos datos no pueden almacenarse en el propio dispositivo, lo que significa que se debe utilizar algún tipo de almacenamiento del servidor para organizar dicho esquema de almacenamiento de datos. No entraremos en esto, ya que nuestra tarea principal es considerar cómo almacenar datos de aplicaciones web en dispositivos.
  

Evaluación del almacenamiento del lado del cliente

Hoy en día, hay muchas API de navegador que le permiten organizar el almacenamiento de datos. Analizaremos algunos de ellos y los compararemos para que le resulte más fácil elegir la API correcta.

Para comenzar, sin embargo, consideremos algunos problemas generales que deben tenerse en cuenta antes de elegir una tecnología específica para almacenar datos. Por supuesto, antes que nada, debe comprender cómo se usará su aplicación, cómo se organizará su soporte y cómo se planea desarrollarla. Al mismo tiempo, incluso si tiene respuestas claras a estas preguntas, finalmente puede ir a varias opciones para los sistemas de almacenamiento de datos, de las cuales deberá elegir la más adecuada. Esto es a lo que debe prestar atención al elegir un sistema de almacenamiento:

• Soporte de navegador. Debe tenerse en cuenta que es mejor preferir una API estandarizada y desarrollada. Ellos, en primer lugar, tienen una vida útil bastante larga, y en segundo lugar, son compatibles con muchos navegadores. Además, las API similares suelen tener una buena documentación y una comunidad de desarrolladores activa.
  
• Soporte de transacciones. A veces es importante que al trabajar con el repositorio, los conjuntos de operaciones relacionadas tengan la propiedad de atomicidad, es decir, que la ejecución del conjunto de operaciones tenga éxito si todas las operaciones fueron exitosas, o si al menos una de ellas falla, fallará. Las bases de datos tradicionalmente admiten esta característica al utilizar un modelo de transacción que puede usarse para agrupar actualizaciones de datos relacionadas en bloques arbitrarios.
  
• Operación síncrona o asíncrona. Algunas API de almacenamiento de datos son sincrónicas, en el sentido de que las operaciones de guardar o cargar datos de dichas API bloquean el hilo activo hasta que se complete la solicitud correspondiente. El uso de API síncronas puede provocar el bloqueo del subproceso principal, lo que puede provocar "frenos" de la interfaz de usuario. Por lo tanto, si es posible, intente usar API asincrónicas.
  

Comparación de almacenamiento

En esta sección, veremos algunos de los sistemas de almacenamiento existentes disponibles para los desarrolladores web y los compararemos de acuerdo con los indicadores descritos anteriormente.

API	Modelo de datos	Metodología de almacenamiento	Soporte del navegador	Soporte de transacciones	Síncrono o asíncrono
Sistema de archivos	Secuencia de bytes	Dispositivo	52%	No	Asincrónico
Almacenamiento local	Clave / valor	Dispositivo	93%	No	Síncrono
Almacenamiento de sesiones	Clave / valor	La sesión	93%	No	Síncrono
Galleta	Datos estructurados	Dispositivo	100%	No	Síncrono
Caché	Clave / valor	Dispositivo	60%	No	Asincrónico
Indexeddb	Modelo híbrido	Dispositivo	83%	Si	Asincrónico

Ahora hablemos más sobre estos métodos de almacenamiento de datos.

API FileSystem

Mediante el uso de la API FileSystem , las aplicaciones web pueden trabajar con un área seleccionada del sistema de archivos local del usuario. La aplicación puede ver el contenido del almacenamiento, crear archivos, realizar operaciones de lectura y escritura.

Esta API consta de las siguientes partes principales:

• Mecanismos para administrar archivos y leer archivos: File/Blob , FileList , FileReader
  
• Mecanismos para crear archivos y escribirles datos: Blob , FileWriter
FileWriter

• Mecanismos para trabajar con directorios y el sistema de archivos: DirectoryReader , FileEntry / DirectoryEntry , LocalFileSystem
  

La API FileSystem no es estándar, por lo que no debe usarse en producción, ya que no funcionará para todos los usuarios. Las diversas implementaciones de esta API pueden variar mucho, y es muy probable que pueda cambiar en el futuro.

La interfaz del filesystem de filesystem de esta API se utiliza para representar el sistema de archivos. El acceso a los objetos correspondientes se puede obtener a través de la propiedad del sistema de archivos . Algunos navegadores ofrecen API adicionales para crear y administrar sistemas de archivos.

Esta interfaz no le da acceso a la página web al sistema de archivos del usuario. En cambio, le permite trabajar con algo como un disco virtual, que se encuentra en la caja de arena creada por el navegador. Si su aplicación necesita acceso al sistema de archivos del usuario, deberá utilizar otros mecanismos.

Una aplicación web puede solicitar acceso al sistema de archivos virtual llamando a window.requestFileSystem() :

 // :    Google Chrome 12: window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem; window.requestFileSystem(type, size, successCallback, opt_errorCallback) 

Si llama a requestFileSystem() por primera vez, se creará un nuevo repositorio para su aplicación. Es importante recordar que este es un almacenamiento aislado, es decir, una aplicación web no puede funcionar con el almacenamiento creado por otra aplicación.

Después de obtener acceso al sistema de archivos, puede realizar la mayoría de las operaciones estándar con archivos y directorios.

FileSystem API es muy diferente de otros sistemas similares utilizados por las aplicaciones web, ya que está dirigido a resolver tareas de almacenamiento de datos en el cliente, que no están muy bien resueltas por las herramientas de base de datos. En general, se trata de aplicaciones que funcionan con grandes fragmentos de datos binarios, o intercambian datos con aplicaciones externas al navegador.

Entre las opciones para usar la API de FileSystem están las siguientes:

• Sistemas de carga de datos. Cuando un usuario selecciona un archivo o carpeta para cargar en un servidor, estos datos se copian en un almacenamiento aislado local y luego, en partes, se envían al servidor.
  
• Aplicaciones que manejan grandes cantidades de datos multimedia: juegos, reproductores de música.
  
• Aplicaciones de edición de sonido e imagen que funcionan sin conexión a Internet o que usan una gran caché local para acelerar el trabajo. Los datos con los que trabajan estas aplicaciones son una secuencia de bytes que puede ser bastante grande. El almacenamiento de dichos datos debe admitir la capacidad de escribirlos y leerlos.
  
• Reproductores de video sin conexión. Dichos programas necesitan descargar archivos grandes que se pueden ver sin una conexión a Internet. Esto puede ser necesario cuando se transmiten datos y para organizar un sistema conveniente para moverse por el archivo.
  
• Clientes de correo electrónico sin conexión. Dichos programas pueden descargar archivos adjuntos a correos electrónicos y guardarlos localmente.
  

Así es como los navegadores admiten la API de FileSystem .


Soporte para la API FileSystem por parte de los navegadores

API LocalStorage

La API LocalStorage , o almacenamiento local, le permite trabajar con el objeto Almacenamiento del objeto Documento , teniendo en cuenta el principio de la misma fuente. Los datos no se pierden entre sesiones. La API LocalStorage similar a la API SessionStorage , el almacenamiento de la sesión, la diferencia es que los datos en el almacenamiento de la sesión se eliminan después de que finaliza la sesión de la página, y los datos en el almacenamiento local se almacenan permanentemente.

Tenga en cuenta que los datos ubicados en el almacenamiento local o en la sesión están vinculados a la fuente de la página, que está determinada por la combinación de protocolo, host y puerto.
Aquí hay información de soporte de LocalStorage navegador LocalStorage para varios navegadores.


Soporte para LocalStorage API por parte de los navegadores

API de SessionStorage

La API SessionStorage le permite trabajar con un objeto de sesión de almacenamiento . La API SessionStorage similar a la API LocalStorage que hablamos anteriormente. La diferencia entre ellos, como ya se mencionó, está en el tiempo de almacenamiento de datos, es decir, en el caso de SessionStorage datos se almacenan mientras dura la sesión. Dura hasta que el navegador esté abierto, mientras permanece después de que se vuelve a cargar la página. Abrir una página en una nueva pestaña o ventana iniciará una nueva sesión, esto es diferente del comportamiento de las cookies de sesión. Al mismo tiempo, al trabajar con SessionStorage y con LocalStorage , uno debe recordar que los datos en dichos almacenes están vinculados a la fuente de la página.

Aquí hay algunos soportes de navegador para la API SessionStorage :


Compatibilidad con el navegador SessionStorage API

API de cookies

Las cookies (cookies, cookies web, cookies del navegador) son pequeñas piezas de información que el servidor envía al navegador. El navegador puede guardarlos y enviarlos al servidor, usándolos al generar solicitudes. Por lo general, se usan para identificar una instancia de navegador específica desde la cual se envían solicitudes. Por ejemplo, para que el usuario, después de ingresar al sistema, permanezca en él. Una cookie es un tipo de sistema de almacenamiento de información de estado de sesión para el protocolo HTTP que trata cada solicitud, incluso desde el mismo navegador, como completamente independiente de las demás.

Las cookies se utilizan para resolver tres tareas principales:

• Gestión de sesiones. El uso de cookies se basa en mecanismos como sistemas de entrada a aplicaciones web, carritos de compras en tiendas en línea, almacenamiento de puntos ganados en juegos de navegador. Se trata de almacenar todo lo que el servidor necesita saber mientras el usuario está trabajando con él.
  
• Personalizacion Las cookies se utilizan para almacenar datos sobre las preferencias del usuario, sobre los temas que elige para diseñar el sitio y sobre otras cosas similares.
  
• Monitoreo de usuarios. Las cookies registran y analizan el comportamiento del usuario.
  

En un momento, las cookies se utilizaron como un almacén de datos de uso general. Aunque esta es una forma completamente normal de usar cookies, especialmente cuando eran la única forma de almacenar datos en un cliente, no se recomienda usarlas como tales en nuestro tiempo, prefiriendo una API más moderna. Las cookies se envían con cada solicitud, por lo que pueden degradar el rendimiento (especialmente en dispositivos móviles).

Hay dos tipos de cookies:

• Cookies de sesión Se eliminan después de la sesión. Los navegadores web pueden usar la técnica de recuperación de sesión, debido a que la mayoría de las cookies de sesión se almacenan permanentemente, como resultado de la sesión se guardan incluso después de cerrar y reiniciar el navegador y abrir la página correspondiente.
  
• Cookies permanentes Las cookies persistentes no pierden relevancia después de la sesión. Tienen un cierto período de almacenamiento, que está determinado por una fecha determinada (atributo de caducidad) o un cierto período de tiempo (atributo de Max-Age ).
  

Tenga en cuenta que la información confidencial u otra información importante no debe almacenarse en cookies ni transmitirse en cookies HTTP, ya que todo el mecanismo de trabajo con cookies es inherentemente inseguro.

Si hablamos sobre el soporte de cookies, entonces, como probablemente ya haya entendido, todos los navegadores las admiten.

API de caché

La interfaz de caché proporciona un mecanismo de almacenamiento de datos para pares en caché de objetos de solicitud / respuesta . Esta interfaz se define en las mismas especificaciones que los trabajadores de servicio, pero no solo es accesible para los trabajadores. La interfaz de Cache también está disponible en el ámbito del objeto de window ; no es necesario usarla solo con los trabajadores del servicio.

Una fuente determinada puede tener varios objetos de Cache nombre. El desarrollador es responsable de implementar cómo su script (por ejemplo, en un trabajador de servicio ) mantiene la caché actualizada. Los elementos almacenados en el caché no se actualizan hasta que se realiza una solicitud explícita para actualizarlos, su período de almacenamiento no caduca, solo se pueden eliminar del caché. Para abrir un objeto de caché con nombre, puede usar el comando CacheStorage.open () , después de lo cual puede acceder a los comandos de administración de caché accediendo a él.

Además, el desarrollador es responsable de borrar periódicamente el caché. Cada navegador tiene un límite codificado en el tamaño de la memoria caché que se asigna a una fuente específica. Puede usar la API StorageEstimate para averiguar la cuota de caché estimada.

El navegador hace todo lo posible para mantener una cierta cantidad de espacio de caché disponible, pero puede eliminar el caché de alguna fuente. Por lo general, el navegador elimina todo el caché o no lo afecta en absoluto. Cuando use cachés, no olvide distinguirlos según las versiones de sus scripts, por ejemplo, incluyendo la versión del script en el nombre del caché. Esto se hace para garantizar el funcionamiento seguro de varias versiones de scripts con un caché. Los detalles se pueden encontrar aquí .

La interfaz CacheStorage proporciona almacenamiento para objetos Cache . Estas son las tareas de las que es responsable esta interfaz:

• Proporcionar una lista de todos los cachés con nombre con los que un trabajador de servicio puede trabajar u otro tipo de trabajador. También puede trabajar con el caché a través del objeto de ventana .
  
• Admite la asignación entre nombres de cadenas y objetos correspondientes de tipo Cache .
  

Para obtener una instancia del objeto Cache , use el comando CacheStorage.open () .

Para averiguar si un objeto Request en particular es la clave de cualquier objeto Cache administrado por CacheStorage , use el método CacheStorage.match () .

CacheStorage acceder a CacheStorage través de la propiedad de cachés global.

API IndexedDB

La API IndexedDB es un DBMS que le permite almacenar datos utilizando un navegador. Como esto le permite crear aplicaciones web que tienen la capacidad de trabajar con conjuntos de datos complejos incluso sin una conexión a Internet, tales aplicaciones pueden sentirse igualmente bien con y sin conexión al servidor. IndexedDB se usa en aplicaciones que necesitan almacenar grandes cantidades de datos (por ejemplo, dicha aplicación puede ser algo así como un catálogo de películas de un determinado servicio de alquiler), y que no necesitan mantener una conexión constante a la red para el funcionamiento normal (por ejemplo, estos son clientes de correo electrónico , administradores de tareas, cuadernos, etc.).

Aquí prestaremos un poco más de atención a IndexedDB que a otras tecnologías de almacenamiento de datos de clientes, ya que, por un lado, otras API son más conocidas y, por otro, a medida que el DBMS de IndexedDB se está volviendo cada vez más popular debido a la complejidad cada vez mayor de las aplicaciones web .

▍ Mecanismos internos IndexedDB

La API IndexedDB permite guardar datos de objetos utilizando la "clave" en la base de datos y leerlos. Todos los cambios realizados en la base de datos se producen en las transacciones. Como la mayoría de estas soluciones, IndexedDB sigue una política de fuente única . Como resultado, una aplicación puede acceder solo a datos que pertenecen a su propio dominio, pero no a datos de otros dominios.

IndexedDB es una API asincrónica que se puede utilizar en la mayoría de los contextos, incluidos los trabajadores web . Anteriormente, había una versión síncrona de esta API destinada a los trabajadores web, pero se eliminó de la especificación debido a que no era particularmente interesante para los desarrolladores web.

IndexedDB tenía un competidor frente a la base de datos WebSQL, pero el trabajo en este estándar fue descontinuado por W3C hace muchos años. Si bien IndexedDB y WebSQL son soluciones para almacenar datos en el cliente, su funcionalidad es diferente. WebSQL es un DBMS relacional e IndexedDB es un sistema basado en tablas indexadas.

No debe comenzar a trabajar con IndexedDB, basándose en ideas aprendidas de la experiencia con otros DBMS. En cambio, será útil leer cuidadosamente la documentación de esta base de datos y utilizar los métodos con los que está diseñada para funcionar. Aquí hay una breve descripción de los conceptos básicos de IndexedDB:

• Las bases de datos IndexedDB almacenan datos en formato clave / valor. Los valores pueden ser objetos estructurados complejos y las claves pueden ser propiedades de dichos objetos. Los índices se pueden crear en función de cualquier propiedad del objeto, lo que puede acelerar la búsqueda de datos y simplificar su clasificación. Las claves también son objetos binarios.
  
• IndexedDB DBMS se basa en un modelo transaccional. Todas las operaciones realizadas con la base de datos siempre ocurren en el contexto de la transacción . Como resultado, por ejemplo, no puede ejecutar comandos ni abrir cursores fuera de las transacciones. Además, las transacciones se confirman automáticamente; no se pueden confirmar manualmente.
  
• La API IndexedDB, en su mayor parte, es asíncrona. Esta API no proporciona los datos solicitados, simplemente los devuelve en respuesta a algún comando. En cambio, al solicitar datos, debe pasar una función de devolución de llamada al método correspondiente. El enfoque sincrónico no se utiliza para guardar datos en la base de datos o para cargarlos desde ella. En cambio, la aplicación realiza una consulta a la base de datos que describe la operación requerida. Una vez completada la operación, se produce un evento que notifica a la aplicación que la operación se completó o no. Este enfoque no es particularmente diferente de la API XMLHttpRequest o de muchos otros mecanismos de JavaScript.
  
• IndexedDB utiliza muchas consultas. Las solicitudes son objetos que reciben eventos sobre el éxito o el fracaso de una operación. Tienen las propiedades de onsuccess y onerror a las que puede asignar escuchas para los eventos correspondientes, así como las readyState , result , errorCode , que pueden analizarse para averiguar el estado de la solicitud.
  
• IndexedDB es una base de datos orientada a objetos. Este no es un DBMS relacional cuyas tablas son colecciones de filas y columnas. Esta característica fundamental afecta la forma en que diseña y crea aplicaciones con IndexedDB.
  
• IndexedDB no usa SQL. Este DBMS aplica consultas de índice que devuelven cursores que se utilizan para trabajar con conjuntos de datos que son resultados de consultas. Si no está familiarizado con los sistemas NoSQL, eche un vistazo a este material.
  
• Los almacenes IndexedDB aplican una política de fuente única. Una fuente es una combinación del dominio, el protocolo y la URL del puerto del documento en el que se ejecuta el script. Cada fuente solo puede funcionar con su propio conjunto de bases de datos, mientras que cada base de datos tiene un nombre único que la identifica dentro de las bases de datos de una fuente.
  

▍ Limitaciones de IndexedDB

El sistema IndexedDB está diseñado con la expectativa de que sus capacidades sean suficientes para resolver la mayoría de las tareas de almacenamiento de datos en el lado del cliente. Está claro que no es un sistema universal adecuado para cualquier caso de uso. Aquí hay algunas situaciones para las cuales no está diseñado:

• Ordenar datos según las características de varios idiomas. No en todos los idiomas, las cadenas se ordenan de la misma manera e IndexedDB no admite la ordenación según las características de los diferentes idiomas. Al mismo tiempo, aunque la base de datos no puede realizar dicha clasificación, la aplicación puede ordenar la información obtenida de la base de datos.
  
• Sincronización La API no se diseñó teniendo en cuenta la posibilidad de sincronizar la base de datos local con el servidor. Tal sincronización, por supuesto, es posible, pero el desarrollador tendrá que implementar los mecanismos apropiados de forma independiente.
  
• Búsqueda de texto completo. La API IndexedDB no admite algo como la declaración LIKE de SQL.
  

Además, cuando trabaje con IndexedDB, tenga en cuenta que el navegador puede eliminar la base de datos en los siguientes casos:

• El usuario dio un comando para eliminar datos. Muchos navegadores tienen secciones de configuración, en las que hay herramientas que permiten al usuario eliminar todos los datos almacenados para un sitio web, incluidas las cookies, los marcadores, las contraseñas guardadas y los datos IndexedDB.
  
• El navegador funciona en modo anónimo. Dichos modos se llaman de manera diferente en diferentes navegadores. En Chrome es "modo incógnito", en Firefox es "modo privado". Una vez que finaliza la sesión anónima, el navegador eliminará la base de datos.
  
• Disco desbordado o llegando a un límite predeterminado.
  
• Corrupción de datos.
  

En general, se puede observar que los desarrolladores de navegadores se esfuerzan por no eliminar las bases de datos IndexedDB a menos que sea absolutamente necesario.

Aquí hay información sobre el soporte de IndexedDB en varios navegadores.


Soporte para IndexedDB por varios navegadores

Elegir un sistema de almacenamiento

Como ya se mencionó, dadas las necesidades de la aplicación, es mejor elegir aquellos sistemas de almacenamiento que tengan un amplio soporte de navegador y funcionen en modo asíncrono, lo que minimiza su impacto en la interfaz de usuario. Estos criterios conducen naturalmente a las siguientes tecnologías:

• Para el almacenamiento de información fuera de línea, utilice la API de caché . Está disponible en cualquier navegador que admita trabajadores de servicios , que son necesarios para crear aplicaciones web que puedan funcionar sin una conexión a Internet. La API de caché es una opción ideal para almacenar ciertos recursos asociados con una página.
  
• Para almacenar datos que forman el estado de la aplicación, o alguna información creada por los usuarios, use IndexedDB. Esta tecnología, en comparación con el almacenamiento en caché, admite más navegadores, lo que amplía la capacidad de los usuarios de aplicaciones basadas en IndexedDB para trabajar sin conexión.
  

Resumen

, SessionStack API . , , - , . , , , - .

Estimados lectores! -?