Body: Haiku could benefit from implementing an automatic real time audio normalization system (i.e. An automatic volume adjustment system) at the mixer level on a per channel basis. It could utilise adjustable normalization schemes based upon given scenarios or channel purposes.
Details Real time audio normalization could be implemented at the system mixer level in Haiku. This system would be designed to boost or soften sounds produced throughout the system to suit listener tastes or given conditions.
Body: If Haiku were to expand and generalise on the popular concept of file and printer sharing there exists the potential for sharing of arbitrary devices, both physical and virtual, over any network. Devices would appear no different from a user's view when compared with local devices.
Details Provider On connection of a shareable device the user's computer would first ensure the device is allowed to be shared and if so, who is allowed to access it.
Body: The ability to mount filesystem's directory structure 'over the top of' existing mounted filesystems would allow for a number of simplifications for Haiku users' systems.
Details Traditionally mounting a filesystem on a specific directory results in the new filesystem 'overriding' the specified directory, effectively hiding the original directory's contents. This restriction could however be lifted, allowing for layered, or union, mounting of systems.
When mounting filesystems the system will keep an ordered list of mount points.
Body: File systems could benefit by adding functionality which would allow files to behave differently based upon which user is currently reading them. Objects could have different contents, permissions and attributes.
Details A file/user polymorphic file system would give file system objects the ability to behave differently, or effectively be different, for each user. It would allow all file information to be selected dynamically based upon entirely upon the current user.
Body: Storing information about devices as attributes in the relevant areas of the devfs could allow much simpler (and more powerful) access to device specific data.
Details There are many items of information regarding physical and virtual devices that require specialised APIs for querying. In order to implement this system an additional set of driver hooks could be added to retrieve the data. It has been suggested that using this method, driver complexity and extensibility (regarding PCI IDs) could be improved.
Body: This proposal suggests an attribute based system to label files as referencing other files in order to allow queries to utilise inter-file relationships.
Details Currently files whose contents reference other files on the local system can only be found through interrogating the file's data or through other similar mechanisms requiring some insight into the file data. It is proposed that a system wide set of attributes be used in order to build relationships.
BodyExtending the OpenBFS/BFS via the usage of calculated attributes for arbitrary files and file types would provide a useful means of dynamic and constantly up to date meta-data on many types of files.
Details On top of the current methods to define and maintain file attributes under OpenBFS/BFS, there could exist methods to define calculated attributes for arbitrary files and file types. The calculation may be based on other attributes of the same file, globally defined values or value lists and other special information like item count for queries or folders.
Body: An advanced form of screenshot could be formed through the use of raw windowing data, SVG and ECMA script allowing for rudimentary interactivity.
Details The operating system has direct or indirect access to a number of sources of raw and scalable data relating to the currently visible (and obscured) screen. This data could potentially be saved in an SVG file and function in a similar fashion to traditional screenshots but retain rendered accuracy throughout resizes.
Body: Fildirutes are an idea for file system naming and simplification. Rather than having separate APIs for files, directories and attributes (and indices too!), you have a single fildirute kind of thing. You can read data from it like a file. You can also open it like a directory and see what's inside. The things inside are fildirutes too. A small one inside would be like an attribute, the name would tell you what the intended purpose was.
Body: Additional methods should be added to all applications which would act to save the current state of each application. All relevant information including (for example) current document edits, window positions and data stream positions should be saved in a standardised way. This would enable easy save, hibernate and start functionality.
Details Single Application Each application should have the ability to save its state at any instant to a predefined file.
