Virtual Filesystems Are Virtual Office Documents
Virtual filesystems can be made into writable virtual office documents. The old UNIX slogan “everything is a file” together with the xsltfs:// virtual filesystem allows for transparently editing relational databases, RDF and arbitrary XML with OpenOffice.org.
The libferris virtual filesystem presents both files and their metadata as a virtual filesystem. The boundaries of what is considered a filesystem by libferris include such interesting data sources as PostgreSQL, LDAP and Firefox as well as standard Web items, such as HTTP, FTP and RDF.
Many virtual filesystems allow directory contents to be synthesized from other directories. The classic example of this is a union filesystem where a collection of existing filesystems are taken as input to generate a filesystem showing the set union of the base filesystems.
Recently, the libferris filesystem has gained support for performing XSLT on a filesystem and exposing the result as a virtual filesystem. To keep things simple, I refer to the original virtual filesystem as the input filesystem and the filesystem that results from the XSL transform as the translated filesystem. As the main use of XSL is to describe translations on trees, this fits nicely for the use of creating translated filesystems.
Although there are differences between a libferris filesystem and the XML data model, there are also many similarities. A file's contents map to the text content of an XML element. A file's metadata is exposed by libferris as Extended Attributes (EAs), which map to XML attributes on the file's XML element. A notable difference between a filesystem and an XML data model is that the document ordering in XML is not always easy to preserve. To keep the mapping simple, a file can generate only one text node in an XML document. Technically, an XML element can have multiple text nodes as children.
Because of the close relation with the XML data model, the libferris filesystem supports viewing any filesystem as a Document Object Model (DOM), which is created on demand. The inverse also is true: you can expose a DOM as a filesystem. As libferris can mount XML as a filesystem, the lines between what is a filesystem and what is XML are somewhat blurred.
Many modern applications store their documents as XML files. As filesystems and XML can be interchanged with libferris, this allows you to use those applications to edit filesystems directly. The main problem with having such applications edit filesystems directly instead of XML is that the schema of the application's XML file usually does not match the layout of the filesystem.
This is where xsltfs:// can be used to create a translated filesystem that matches the layout the application is expecting. For example, you could take a table in a PostgreSQL database as the input filesystem and have the XSL massage that table into a virtual spreadsheet file, which you load into OpenOffice.org.
The possibilities become even more interesting when write support in the translated filesystem is considered. After you have made some changes to the above virtual spreadsheet file in OpenOffice.org, you “save” the file. The filesystem then applies a reverse XSLT and updates the input filesystem (in this case a PostgreSQL table) to reflect your changes.
To support this, you have to have two XSL files. The first stylesheet translates an input filesystem into the format you are interested in. The second XSL file (the reverse stylesheet) provides the inverse translation. In the future, the second XSL file should become optional if it can be inferred from the actions of the initial translation.
Reverse stylesheets can specify updates either using explicit URLs for each file to change or relative paths. The explicit URLs method expects the reverse stylesheet to specify the absolute URL for each file to be updated. This can be convenient for xsltfs:// applications where URLs play a role in both the source and translated filesystem. For example, when editing some RDF files with OpenOffice.org, the subject URI will be available to allow the reverse stylesheet to use explicit updates.
The relative paths method is conceptually similar to applying diff and patch to your filesystems. The reverse stylesheet generates a list of changes to make using a relative path for each file to change. Some options from the patch utility are available to the reverse stylesheet as well. The root element can contain a strip attribute that works similarly to the strip option of patch. The autocreate attribute, when set to true, will make libferris try to create new files where the reverse stylesheet specifies a relative path that does not exist in the source filesystem.
Currently, both reverse stylesheets must supply the entire contents of each file to update. This is not a major drawback, as that information already will be fully available in the translated filesystem.
The following sections show two uses: creating new virtual filesystems and directly interacting with them from the console and creating virtual office documents. This is followed by some advice for creating custom stylesheets by hand.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Google's Abacus Project: It's All about Trust
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Seeing Red and Getting Sleep
- Secure Desktops with Qubes: Introduction
- Fancy Tricks for Changing Numeric Base
- Back to Backups
- Working with Command Arguments
- Secure Desktops with Qubes: Installation
- CentOS 6.8 Released
- Linux Mint 18
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide