Body: The means of having the operating system automatically sort, file and perform actions on filesystem objects based on user-configurable criteria should be provided through the use of a "drop target" replicant known as the "Sorting Chute".
Details The sorting chute would be comprised of three main components:
Replicant Preference Applet Drop Folder Replicant The replicant would act as a space on the desktop, designated by an appropriate visual representation, whereby filesystem objects can be dropped to have actions invoked upon them based on a set of user-defined rules.
Body: Haiku could include a dedicated API and an additional server who's task would be to manage and optimise simultaneous downloads on a global level.
Details In order to optimise downloads from a Haiku system it is proposed that all mass downloads be conducted using a dedicated download kit. Any software which wanted to download large files should use the download kit API to queue the download, query it's progress and other management tasks.
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.
