--- title: Grupo de recursos de BrightSign slug: develop/es/grupo-de-recursos-de-brightsign docTags: createdAt: 2025-03-11T07:07:19.526Z --- El BrightSign Asset Pool proporciona un mecanismo confiable y resistente para descargar, almacenar y recuperar recursos multimedia y otros archivos requeridos por el reproductor para sus presentaciones. ## Conceptos principales ### El pool Un pool de recursos es una jerarquía de directorios bajo una única raíz. El directorio suele denominarse simplemente "pool", pero la implementación subyacente no lo requiere. Cada recurso se almacena en uno de varios subdirectorios para mejorar el rendimiento en sistemas de archivos simples como FAT. El destino de un recurso concreto en el pool se determina mediante el [hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) (o digest) de su contenido (o, en algunos casos, un hash de sus metadatos), lo que lo convierte en un almacén direccionable por contenido. Para poder hacer referencia a un recurso antes o después de que se haya descargado, es necesario conocer su hash. (Esto es similar a la forma en que se almacenan los objetos en un repositorio Git.) El pool puede configurarse con un tamaño máximo y/o para garantizar que una determinada cantidad de espacio permanezca libre en el dispositivo de almacenamiento que lo contiene. Para evitar que el pool crezca más allá de estos límites, los archivos antiguos se "podan". Los archivos que no deben podarse deben "protegerse" antes de iniciar cualquier operación que pueda escribir en el pool. Un recurso que se almacena en el pool usando un hash concreto solo se almacenará una vez hasta que se pode. Las solicitudes para descargar un recurso que ya está en el pool tendrán éxito inmediatamente, ya que el recurso ya está presente. Esto significa que cambiar entre presentaciones que comparten recursos, incluso quizá algunas que no se hayan usado durante un tiempo, puede evitar descargas innecesarias de recursos. ### Colecciones de recursos Una colección de recursos es una lista de metadatos de recursos. Los metadatos contienen directamente el hash como un campo específico o el hash puede generarse directamente a partir de otros campos. Los metadatos también proporcionan un nombre para cada recurso, lo que permite buscar recursos y, por tanto, archivos en el pool por nombre. Una colección de recursos es necesaria para dar significado a los recursos almacenados en el pool. Las propias colecciones de recursos existen solo en memoria y no se almacenan en el pool. ### Especificación de sincronización Las especificaciones de sincronización suelen denominarse "sync specs". Consisten en XML o JSON formateados que pueden utilizarse para generar una colección de recursos, pero también tienen espacio para información adicional que puede resultar útil al descargar recursos. No se recomiendan a menos que se requiera compatibilidad con sistemas existentes que las utilicen. ### Recuperador de recursos Un recuperador de recursos se ejecuta de forma asíncrona descargando cualquier recurso mencionado en una colección de recursos que no esté disponible actualmente en el pool. El contenido del archivo se verifica automáticamente con respecto al hash proporcionado durante la descarga. ### Protocolos Se espera que los recursos se descarguen principalmente mediante HTTP o HTTPS. Sin embargo, el recuperador también admite FTP y URL de archivos. ### Autenticación Se pueden proporcionar encabezados HTTP arbitrarios al recuperar todos los recursos de una colección de recursos. El recuperador admite autenticación HTTP Basic, Digest y NTLM. Los recursos individuales dentro de una colección pueden marcarse para excluir el uso de estos encabezados y autenticación. ## Administración del tamaño del pool El pool está diseñado para existir durante mucho tiempo, obteniendo recursos en él según sea necesario. Si el pool se llena demasiado, los recursos no utilizados se podarán para liberar espacio. Esto significa que cualquier recurso que todavía sea necesario (o vaya a ser necesario) debe protegerse antes de realizar cualquier operación que pueda podar recursos, como la recuperación o la materialización. El tamaño del pool puede restringirse de dos maneras: - exigiendo que una determinada cantidad de espacio en el dispositivo de almacenamiento permanezca siempre libre. Esto significa que puede reservarse espacio para que los registros aumenten de tamaño y cualquier operación del pool que pueda podar garantizará que al menos la cantidad solicitada de espacio permanezca libre. Comprobar la cantidad de espacio libre en un dispositivo de almacenamiento es una operación ligera, por lo que debe preferirse este método. - estableciendo un tamaño máximo que puede ocupar el pool. Esto puede utilizarse en combinación con el método anterior y el intento de superar cualquiera de los dos umbrales activará la poda. Calcular el tamaño del pool requiere sumar el tamaño de cada archivo individualmente, por lo que la primera operación puede tardar más de lo habitual. Una vez completado el primer cálculo, el tamaño del pool solo se actualiza en función de las modificaciones del pool, por lo que las operaciones posteriores tienen menos sobrecarga. Los archivos se consideran para poda según cuánto tiempo haya pasado desde la última vez que se recuperaron o se habrían recuperado si no hubieran estado ya presentes en el pool. Los archivos no protegidos recuperados hace más tiempo se podarán primero. Tenga en cuenta que, a menos que el "conjunto de trabajo" de recursos esté cerca del tamaño máximo del pool, esto a menudo puede significar que cualquier fallo al proteger recursos no tenga efectos negativos. ## Referencia a recursos en el pool Los archivos de recursos a menudo pueden utilizarse directamente desde el pool. El nombre de archivo del pool correspondiente a un recurso puede buscarse por nombre en una colección de recursos. A veces es necesario que los archivos de recursos aparezcan con sus nombres dentro del sistema de archivos. Los archivos de recursos pueden copiarse a un directorio de destino. Esto se conoce como "materialización" y solo debe utilizarse cuando sea necesario, ya que puede ser muy lento. Como alternativa, puede hacerse que una colección de recursos aparezca como un sistema de archivos virtual. ## Unicidad del hash El hash de un archivo de recurso concreto debe ser único. Esto ocurre automáticamente con algoritmos hash normales como SHA-256, ya que no deberían ser posibles las colisiones hash. Si dos archivos con contenido diferente generan el mismo hash, esto se conoce como una "colisión hash". Se sabe que algunos algoritmos hash más antiguos, como MD5 y SHA-1, tienen colisiones hash, pero estas solo ocurren cuando los archivos han sido construidos deliberadamente para crear dichas colisiones; no ocurren por accidente. A veces el hash real del recurso no está disponible antes de la descarga. En este caso, se aplican funciones hash conjuntamente a partes de los metadatos del recurso, como la URL y una pista de cambio. Si el recurso cambia, entonces alguna parte de los metadatos también debe cambiar para que el recuperador de recursos sepa que debe descargar el recurso nuevamente. No es posible utilizar encabezados HTTP como ETag o Last-Modified como parte del hash, ya que estos no se conocen antes de la descarga y pueden cambiar de forma independiente. ## Metadatos de recursos | **Etiqueta** | **Descripción** | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name | Nombre de archivo relativo (puede contener barras, pero en ese caso el archivo puede no materializarse). Los nombres de assets deben ser únicos dentro de una colección de assets, pero se espera que diferentes colecciones de assets contengan assets con el mismo nombre. El nombre del asset no se almacena en el pool, y el mismo archivo de asset en el pool puede ser referenciado por múltiples nombres, incluso dentro de la misma colección de assets. | | size | Longitud del archivo en bytes | | hash | Algoritmo hash y hash del contenido del archivo. | | link | URL de origen | | change\_hint | Un valor arbitrario utilizado por el cliente para garantizar que los archivos que tienen el mismo hash no se consideren idénticos a menos que este valor y la URL también coincidan. | | auth | Especifique información de autenticación adicional (consulte a continuación). | | probe | Datos de sondeo de medios (útiles para Cheetah y Panther). | | pattern | Patrón comodín contra el cual hacer coincidencias | ## Hashing ### Algoritmos hash simples md5, sha1, sha224, sha256, sha384, sha512 ### Algoritmo BESHA1 Este algoritmo solo es útil para hacer referencia a contenido remoto que es demasiado grande para descargarse durante la creación. Su uso no es recomendable. ### Sin hash Si no se especifica ningún hash, entonces el hash se genera internamente combinando mediante hash los campos "link" y "change\_hint". ## Descripción general del uso El pool de assets de BrightSign puede usarse desde BrightScript o desde Javascript, pero no es posible compartir un único pool entre ambos. Sin embargo, el método BrightScript  `roHtmlWidget.MapFileFromAssetPool` puede utilizarse para hacer que una colección de assets en particular aparezca como archivos bajo un prefijo URI en particular. ### BrightScript TBD ### Javascript 1. Cree un objeto @brightsign/assetpool para representar el pool de assets pasando la ruta al directorio del pool. 2. Cree la estructura de datos de la colección de assets. Este es un arreglo JavaScript de objetos que contiene los metadatos de los assets que desea usar. 3. Proteja los assets llamando al método `assetpool.protectAssets` para evitar que se eliminen con el fin de liberar espacio. 4. Cree un objeto @brightsign/assetfetcher pasando el pool. 5. Llame al método assetfetcher.start pasando la colección de assets. Cualquier asset que no esté presente en el pool comenzará a descargarse. 1. El progreso puede supervisarse agregando controladores para los eventos progressevent y fileevent. 2. Si el intento de obtención se completa correctamente, entonces la promesa devuelta por assetfetcher.start se resolverá. Si al menos uno de los assets no pudo descargarse completamente, entonces la promesa será rechazada. 3. Cuando se resuelva la promesa devuelta por assetfetcher.start, el intento de obtención estará completo.  6. Cree su conjunto de assets como un arreglo JavaScript de objetos que contienen los metadatos. 7. Cree un objeto @brightsign/assetfiles pasando el pool y la colección de recursos. Este objeto se puede utilizar para recuperar la ruta completa a los archivos en el pool que corresponden al nombre del recurso especificado. Consulte [assetpoolfiles](docId\:o-UUt2YL90KzC5nT8i0Hv) para obtener más información. 8. Cree un objeto @brightsign/assetrealizer pasando el pool y llame al método realize si desea copiar recursos desde el pool a un directorio utilizando los nombres de los recursos. Tenga en cuenta que esto es lento y solo se recomienda para archivos que deben existir en el sistema de archivos, como los archivos de actualización de BrightSignOS (bsfw). 9. Cree un objeto @brightsign/assetcollectionview pasando el pool y la colección de recursos para crear un dispositivo de almacenamiento virtual que contenga los recursos utilizando los nombres y la estructura de directorios de la colección de recursos. Consulte [assetpoolfiles](docId\:o-UUt2YL90KzC5nT8i0Hv) para obtener más información. ## Ejemplo [Ejemplo de grupo de recursos de BrightSign](docId\:vWU1okQBrjWyQJNKSx5MI) muestra cómo se puede utilizar Asset Pool desde JavaScript. Funciona tanto desde NodeJS como desde Chromium, y se puede ejecutar desde el shell de BrightSign de la siguiente manera: ```javascript node bs-assetpool-example.js ```