For a program system to be able to process any number of one or more program resources -- resources such as would represent source code or compiled object data, such as would affect the runtime execution environment of the program system, on load -- a program system must first locate the program resources.
After locating a program resource -- as whether located via a kernel fileystem service or userspace application service -- the program system may then establish a data connection to the service by which the program resource has been located. In a manner of typical file input procedures, in an instance of an operating system kernel implementing a POSIX model for system procedures -- such as Linux or FreeBSD -- the data connection establishment procedures might be represented by the program resource establishing a file descriptor onto a filesystem resource, via a C 'open' or 'fopen' function. For accessing a program resource via a compressed archive file, alternately -- such as for program resources stored within Zip format Java Archive (JAR) files -- broadly, a data connection may be established for accessing the compressed archive containing the program resource, then any one or more archival procedures may be performed such as to retrieve the individual program resource from within the same compressed archive. In a third example, for accessing a program resource via a trusted WebDAV service, firstly a network application session may be established to the WebDAV service, then secondly a data connection may be established for accessing the individual program resource as via the network application protocol implemented by the respective WebDAV service.
Subsequent to that a data connection would be established -- as to access a media object effectively representing the contents of a program resource -- the contents of the media object would be processed to an effect of loading the program resource into the program system's program space. Lastly, the program system may endeavor to perform programmatic operations such as would have been loaded into the program system's program space, originally from the program resource.
Orthogonal to the procedures of data connection establishment and program resource loading, then -- as specifically considering an example of accessing a program resource from within a JAR archive file -- effectively the example may serve to lend to a sense of filesystem containers. A JAR archive file, broadly, is a compressed archive file with a specific internal archive format -- more specifically, an archive file compressed with Zip compression, secondly the archive file having a specific internal filesystem format. As a special manner of archive file, a JAR archive file serves as, effectively, a filesystem container for Java program resources. Typically, a JAR archive file may be accessed by a Java Runtime Environment (JRE) as for a purpose of load program resources -- such that those program resources would typically have been compiled with the 'javac' compiler of a Java Development Kit (JDK). A JAR archive file, more broadly, may serve as a container of non-program data resources, such as of configuration data and static graphical interface object data.
Aside to any manners of specific, semantic differentiation of data resources -- as with regards to semantic differentiation of program data resources and non-program data resources, as in regards to structures and applications of data resources -- with an example of the JAR archive file as a singular keynote, an abstract container model may be designed for modeling of data resources. The abstract container model, however developed, may be expressed for applications in a portable, platform-agnostic format such as CORBA IDL. In applications, the abstract container model may be implemented such as for an application to provide CORBA object services onto any number of resource types, as may include: Archive files; networked application protocols providing filesystem services; filesystem directories; individual filesystems; application-defined structures such as of ASDF system definitions, Apache Maven Project Object Model (POM) definitions, or individual software package structures.
Broadly, towards a definition of CORBA Object Services for access onto filesystems, two examples may be considered: CORBA Audio / Video services [Han2004] and DOM 3 Load and Save [DOM3LS]. In albeit a naive sense, a CORBA Audio / Video services implementation may serve to provide an number of stream-oriented multimedia playback and control services via a networked CORBA architecture. DOM 3 Load and Save, beyond any specific applications in the document object model, may serve to provide -- broadly -- a structured, event-oriented approach for file data processing via a networked CORBA architecture. Hypothetically, any number of extensions may be developed for applications of DOM 3 Load and Save functionality, in a manner broadly orthogonal to representations of Document objects in in the Document Object Model (DOM), more specifically extending of an event-oriented data structure processing model as developed of DOM.
In a manner of narrowing a design of an abstract container model for data resources, in focusing -- broadly -- on structured formats of individual data resources: Any single file type data resource, in itself, may be modeled as a container for persistent object data, such as may be encoded within a single file data resource.
Hypothetically, an object storage filesystem may be defined, such that the object storage filesystem may store and retrieve persistent object data in a format specifically of object types and object data fields -- in a sense, focusing on storage and retrieval of object data structures such as of DOM Document objects, not expressly focusing about storage and retrieval of object data serialization structures such as files, filesystems, and file archives.
In an implementation onto an existing operating system -- inasmuch as that an object storage filesystem may be implemented onto an existing filesystem architecture -- a filesystem architecture such as may be underly an object storage filesystem may need not be -- in itself -- defined as to be expressly "Pretty printed" in any single structural list. If an object storage filesystem may present at least a human readable view of objects stored in the object filesystem -- not either in obviating concerns with regards to data access rights -- then any object data services, such as may be defined in an implementation of an object storage filesystem, may store and retrieve data onto an operating system's underlying filesystem device, using any single baseline file naming scheme and any collection of specific file formats such as may serve to allow for an efficient storage and retrieval of object structure data, in the respective object data services.
Not as though to propose to reinvent an operating system, an object data storage system in Common Lisp -- when implementing a CORBA architecture in Common Lisp -- may effectively "Borrow" the CDR encoding format implemented in CORBA IIOP. Perhaps a CDR implementation, furthermore, may be refactored for marshalling and unmarshalling of object data onto a filesystem -- juxtaposed to marshalling and unmarshalling of object data within a network peer services architecture.
So, hypothetically, a single CDR Serialization service may be defined, such that the CDR Serialization service would effectively serve as a channel encoder/decoder for object data as may be stored onto persistent media.
This is not as though to recommend that a CDR Serialization service would be applied as if to instantaneously persist data structures and values for every object initialized within a program system. Certainly, in a hypothetical embedded computing platform, the figurative tires of a serialization service might wear out a figurative NAND/NOR road, if the figurative tires would be run on the figurative road, too frequently. That is to denote, as by way of an analogy, that a memory technology device (MTD) may allow for only a limited number of store/load cycles for data stored in the MTD's NAND/NOR firmware, without degredation of the MTD's storage capacity -- aside to any nondeterministic metaphors as of road maintenance for MTD applications.
So, in designing a model for a program system suh as may implement an object data serialization service -- as may extend of a conventional filesystem service -- a distinction may be drawn between runtime data structures and persistent data structures. As one possible juxtaposition: A distinction may be defined in a sense of a failover view, such that If a set of runtime data strutures would not be recorded onto persistent media, that it would not irreversibly degrade the performance of an application, if the data structures would be effectively "lost" as due to termination of a processing thread, if not a complete system power cycle in the underlying computing platform.
In another sense of a juxtaposition of persistent and runtime data structures: A discrete set of filesystem data records may be processed by an object storage service, such that a persistent data structure may be initialized of the contents of the filesystem data records. Subsequently, the filesystem data records may be updated -- certainly, updated in a transactional regards -- updated for any changes in any corresponding data fields within the persistent data structure. A persistent data structure, in itself, might make reference to any one or more runtime data structures, such that would not be recorded onto a persistent filesystem media, though referenced by a persistent data structure. In a description of such a view, it might furthermore be noted that an object storage service may be defined as an abstraction of table-oriented data storage models, such as may be implemented with regards to portable SQL.
In a sense with regards to storage models for tabular application record structures, perhaps the former might be juxtaposed to a more generic file-oriented data storage model, as in that a tabular storage model may serves to add any set of structures for tabular storage of persistent data records, essentially specializing a generic persistent storage model, in the abstract application space.
Towards a further juxtaposition of runtime data and persistent data, a juxtaposition may be presented as with regards to an orthogonal concept, broadly, of how applications process data. In albeit a broad case study of a hypothetical application, Bazomatic, the Bazomatic application may store a certain selection of data values into a structured format in persistent data storage. On processing of any set of persistent data values as thusly stored, the Bazomatic application may create any discrete number of relational data values in the Bazomatic application runtime data space, as for purpose of maintaining a sense of data structure among the data values originally stored into persistent data storage. The relational data, as such, may need not be stored expressly into the persistent data files -- the relational data being represented, in an application-specific manner, as though in implicit relations among persistent data values, in the structured record format of the Bazomatic data storage model.
Beyond a view with regards to data record formats, moreover an application program may create any number of runtime data values as to represent, structurally, any specific set of qualities of system devices such as may be accessible to an application's runtime environment -- such as of individual keyboard, mouse pointer, touchscreen, LED, printer, or other input/output devices.
Of course, with regards to data presentation, an application may likewise store any relatively small number of persistent session data values, within any single computer system user's own data storage space -- such as of window positions, in an application session of a graphical windowing environment. A system user's own persistent session data may be applied within an application system, as for purposes of configuration of application session properties, across any single application session durations.
In a manner more functionally fundamental than the data presentation systems of any single computing environment, a computer system may furthermore present any number of persistent data storage devices and network data communication interfaces, in a manner internal to the computing system's own runtime operating system. In regards to network data communications interfaces, orthogonally, the author wishes to make a note with regards to the Netgraph architecture implemented in FreeBSD. If the Netgraph architecture may be extended for direct access to persistent data storage devices, perhaps such extensions may furthermore make reference to the FreeBSD virtual process jails model -- as perhaps towards an altogether abstract model extending of real implementations of services for data storage and data communications, within a contemporary computing environment.
Orthogonal Concept: Offloading Filesystem Handling to Kernel/Userspace Filesystem Adapters - FUSE
An outline for any good' ol' "TL;DR" synopsis
- FUSE: Filesystem in Userspace
- GNU toolchain
- Linux Kernel - VFS Drivers
- FUSE Support in FreeBSD
- FUSE Filesystem [FreeBSD Project - Wiki]
- Filesystems on FreeBSD [FUSE Project -Wiki @ SourceForge]
- Ports - Active: Fusefs [FreshPorts Search]
- Highights for multi-boot enviroments - fusefs
- With FuseFS configured in a [host, hosted virtual jail, or a Bhyve VM environment], applications may access local/remote filesystem resources via normal kernel filesystem protocols.
- FUSE allows for implementation of filesystem protocols, with the underlying filesystem services being functionally transluscent to the filesystem service client
- Contrast to: ZFS
No comments:
Post a Comment