The Problem: Currently, when you want to open, convert, or create a particular file, you must find the program that has the ability to open or save that particular file type. This is further complicated by the fact that the particular program, like an image editor (designed to manipulate bitmaps) often does not have the capability to handle all the various formats that are available. The problem thus requires installing and using additional programs in order to accomplish the simple task of opening, converting, or saving a particular file type. This method is neither productive for the professional, nor helpful to the beginner. Summary: In the spirit of "It should just work," we should offload the ability to handle file formats from the program to the OS itself. Thus, introduce the ability for Haiku to natively handle various file formats. Details: The actual details of how to implement this are left up to those who know how to do this best. Possibility include developing an API that must be included in any Haiku program that wants the ability; another possibility includes adding the feature to the file system itself. Anyways, to gain a basic idea of how this system might work, it may be best to actually divide file types into categories such as: video audio bitmap vector text word processing etc... As you may notice, these categories are closely aligned with the various types of programs that are on the market (bitmap image editors, vector image editors, word processors, video players, etc...). Each of these categories usually consists of a number of different file formats: video - (wmv, avi, mov, qt, rt) audio - (mp3, ogg, wav) bitmap - (bmp, tiff, gif, png, jpg) vector - (svg, ) A likely way for the system to work would be for a program to request a particular category of file type, and the OS handle the conversion process. For example, an image editor would request information in raw bitmap format. The OS would then be able to process the varoius bitmap files that is supports (bmp, png, gif, etc...) and serve it up to the application. This is, of couse, a very simplistic approach to the issue. There are actually many issues to consider in the process: .... I won't include all that in this email ... anyways, would any developers like to discuss this issue via email or chat via AIM or MSN?