Kernel

This article was started by myself, but it was extended by our users when it was placed on our wiki. The development team will have to review and discuss all suggestions.

Multi-User

• something similar to what Win2k does, where you try to do something and it says "you don't have permission to do that. If you are an admin, click here to enter the admin password for permission."
• multiple users - One or many at a time? Security for many at a time?

New Kits

• vector math library to use MMX/SSE/SSE2/3/4/5
• What about having a synthesized speech kit. Applications would send text (possibly with special marks) to the kit. Particular languages could be available as plug-ins.
• Voice recognition
• Should we have help system? Pocket PC has very handy one, it's HTML-based. There's a folder somewhere, where your help files are (for example, StyledEdit.htm). When you have StyledEdit opened and you open help, it goes directly to the StyledEdit.htm file. When there's just an empty desktop and you open help, it goes to index (automatically updated links to files in help folder). So, whenever you install a program, the install script or package manager copies just one HTML file to the help folder. It's so easy to use, that OBOS should have it too. And there could be a simple search capability within the help files
• synchronization kit - some sort of way to notify and automatically update subscribers when data changes
• im kit
• XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit
• Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)
• Database Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better. Look at SQLAlchemy for inspiration.
• Fax support (kit?)
• RPC (SOAP, XML, Web services etc.)
• SpellCheckAPI
• Reference kit (dictionaries, thesaurus)

Media/MIDI

• a BSound class that adds effects? Mute, slide, reverb, echo, etc. All, again, as plug ins.
• subtitles
• audio tracks for different languages
• interactive menus (e.g.: DVD)
• support more sources (HTTP, CD/DVD, TV)
• integrate Media and MIDI kits into one kit. there was an RFC at GlassElevator about this
  
• DRM modules (with TPM support), so we can use iTunes and the other services. see gstreamer for an example of how to add support for this
• take a look at Infopipes concept
• http://www.cs.pdx.edu/~black/publications/
• http://www.cs.pdx.edu/~black/publications/Mms062%203rd%20try.pdf
• http://www.cs.pdx.edu/~black/publications/Koster%20m3w.pdf
• http://www.cs.pdx.edu/~black/publications/infopipe_dos.pdf
• http://www.cs.pdx.edu/~black/publications/Directflow.pdf
  

Printing

• Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

Device Kit

• Why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your Haiku machine should have a class to access it.

Game Kit

• Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more.
• Translation Kit
• How about 3D objects? Or vectors (structured drawing)? HTML read/write?

Mail Kit

• public/private key encryption for email

UI

• ditch menu bars for context menus only
• we should go vector. And we should adopt SVG as our standard.
• Dictionary of translated words, so that untranslated apps can be automatically (if imperfectly) translated.

How about being able to have a several applications using the same window, each one having its own tab? I believe there are UNIX window managers that do this though I've not tried them so I'm not sure how good it is in practice. I imagine there would be pros and cons.

Some GUI description language (XUL?) is a really nice thing to have in R2.

include a standard widget for toolbars, Some thinks I like about some toolbars:

• drop-down buttons.
• animated icons.
• separators
• options per toolbar - small icons, text under icon.
• !!! configuration tool - add/remove button on the fly !!!
• ability to collapse the menubar into a clickable icon for more screen space (maybe even into the tab?)

Additions to BBitmap - this class is really in need of a lot more "stuff". Think LeadTools for Windows - the ability to choose some area of the bitmap and apply transforms (plug ins). This has been done a dozen times for a dozen different art programs. Let's do it once more, possibly leveraging someone else's work and make it part of the OS.

• BHTMLView - include JavaScript? External players? Use some existing framework?
• How about an Outlook bar? Or a grid widget? Many new controls possible, look at other OSs. Graphs and charts
• How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file? Still-Image Acquisition & Moving-Image Acquisition
• RAD / easy graphical GUI-creation toolkit
• Color Management
• Multiple monitor support
• LayoutManager (already in the works for R1)
• workspace sharing via network
• investigate ZUI concepts
• access embedded data (e.g.: email attachments) in-place
• spatial data organization
• look at Morphic/Tweak, Chalk (Slate's CLIM+Morphic combination)
• replicant may run as separate process?
• OpenBinder
• scalable UI
• gamma correction?

Localisation

This would be fantastic it would allow easy language localization of any part of OBOS (OS included) to a specific language and it would allow for users to have several languages available in is system in just one installation.

All higher layers of system should use some kind of localisation. This covers:

• Language translation files for applications
• Time and Date writing order/conventions
• Currencies
• Number spacing
• Keyboards
• Fonts ( BeOS default fonts are lacking some Latin European glyphs )
• API/GUI should be able to fit different font sizes and string lengths (Example: Chinese has very big chars)
• system–wide Unicode/UTF-8 is a must

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar, number widgets, phone number, address that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right. Layout management, too, so that resized widgets can flow properly.

Note: Axel Dörfler is already working on this in the OpenTracker repos.

Kernel & Drivers

• ability to move processes from one machine to another (load balancing)
• Anyway, a good thing to add is device feedback. This way drivers would be able to implement force-feedback for mice, for example.
• A method for drivers to publish functionality in a standard way. It could be only metadata. It would allow querying to discover if certain functionality exists in the driver and/or the hardware
• Power Management and other "special" laptop support
• Bluetooth
• FireWire
• CardBus/PC Card
• PCI Express
• 64-bit processors
• Debugging via the kernel
• RAID (hardware and software)
• Hardware–accelerated OpenGL
• EFI (UEFI 2.1)
• Enhanced SpeedStep
• WiFi (2200BG, 2915ABG, 3945ABG, PRISM?, USB adapters, ...)
• Firewire
• Intel graphics drivers
• more file systems (NTFS r/w, UDF2.6+attrs r/w, ZFS, XFS?, EXT2/3FS?, ReiserFS?)
• FS-independent indexing service (e.g.: Beagle), but might use FS index (if available) for faster queries
• userland FS API
• LDAP address book
• IMAP
• IMAP address book + calendar + notes [plug-in based backend]
• WebDAV?
• FTP
• P2P with queries [BeShare?]
• transactional VFS (see Windows Vista)
• versioning VFS
  
• FS ACLs
• extend node monitoring to monitor all VFS calls
• not only specific directories
• allow for filters that can intercept and deny access (e.g.: virus scanners)

Network

• ZeroConf / Rendezvous / uPnP
• with support for add-ons: e.g., instant messengers could use ZeroConf to expert services to your friends
  
• event-driven API (new device, configuration changed, (dis-)connected, etc.)
• mobility-oriented
• access important functions and profiles via Deskbar replicant
• auto-recognition of profiles
• update default printer and PPP connection
• update timezone?
• IPv6
• WiFi with full encryption support (WEP, WPA, WPA2)
• RADIUS client authentication
• anonymizer modules (Tor, DNS translation, etc.)
• NDIS wrapper
• networked file system

BeMail

• show all drafts in a list on the left
• closing will auto-save your email. no need to save your work
• unlimited undo history is stored for all drafts, so you can undo something even after having closed BeMail

Tracker

• Not only does it offer a more efficient space, it enhances the usefulness of the OS by offering a place to stash information vital to the user. Some examples of replicants that could be of use would be a pulse like CPU histogram, a virtual workspace manager, a clock and calendar, controller for audio players, applications/script/folder shortcuts and a drive space monitor, to name a few. I'm sure others can come up with more. It would be left up to the user to decide what they want to display as a deskbar replicant, in what order they want them displayed and how they want it displayed.
• what if "My Computer" opened into a mime type directory. You could either look at a type's subtypes OR look at the files with that mime type.
• In the Tracker with an icon(or icons) highlighted, you decide to copy them to another directory. You simply right click, move the cursor over Copy To and you then proceed to find the directory you wish to copy them to. Now you find a few more files(we will use mp3s as an example) that you wish to copy to the same directory. You simply right click, move the cursor down to Copy To, but this time when the next menu forms their is an option at the top that says Most Recent or Recent. Moving to the right on this item shows you the last 5 or 10 directories that you have copied to. This functionality would be available from the Create Link, Copy To, and Move To pop–up menus.
• integrate xcv ([1])
• This could be implemented like this: when the appropriate file is highlighted, make Tracker extend its viewable area, like a drawer, and this drawer should work like R4's Container; attach a new replicant that can handle this file type. BeMail could be made a replicant, NetPositive already is (could be the handler for graphic files), SoundPlay also...
• Folder backgrounds are stored as an attribute of the folder. Why can't we preview images by clicking once on them and have Tracker send them into the open folder's background attribute? For that matter, any type of data/media could be handled the same way. Video, audio - all that stuff. We can even have tracker do cool things like make a split pane to preview emails and text documents (any kind of document that we have a "tool" reader for - Gobe, Word, Abiword, etc.).
• What about allowing "rules" for file management on the desktop, i.e. when files are dropped there.
• rework queries and UI (categorization, time-slider/scroll-to field)
• http://dabbledb.com/
• http://smallthought.com/clips/lispvan.mov

BFS

I think it would be useful to have attributes with both a name and an index: you could get the 6th attribute named "foo", for instance. This is useful because it lets you associate more than one value with a single attribute in a system-defined way. If we had an installer that tracked what libs an app depended on, it could place those in attributes and query for them, without worrying about separating the lib names with some kind of token. MP3s could have multiple authors. We could also give translators an attribute for what they translate, which would make this obvious to the user, *and* obviate the roster: the system would know where it was going. Currently, we have only one value for attributes which is very annoying with a Contact's email addresses: we use tricks like "Person:Email"="first@mail.com, second@othermail.com". This has to be changed. Think of BMessage: "Person.Email" gets an array of values: "Person.Email"[0] = first@mail.com "Person.Email"[1] = second@mail.com How this is handled with indices: the "Person.Email" index may simply contain multiple entries pointing to the same file.

• Full text indexing.
• versioning
• maybe replace BFS with a DB (DR8, but much better)
  

Components

The micro solution consists of reverting to the computing roots of the D+F concept (data and functions, no programs). That is, the killer app for GE is that there is NO app. Your system consists of functions which the user invokes in which ever order they choose, and vendors ONLY provide functions. They no longer provide programs. The entire User Interface has to be changed to allow for an entire different concept of work flow. Let me repeat that one more time - a new work flow requires a change in the user interface (think fundamental change like the change from CLI to WIMP).

I connect the Cron component to the MediaPlayer object and boom - alarm clock. This is what OO was supposed to bring to coders. We are talking about bringing it to end users. Of course, just like, say, themes, there will be builders and there will be users. But what we are really talking about is making coding message based and more modularised. The idea of wrapping complex structures in one binary file & using special dev/apps tools to poke inside seems to be giving way to keeping 1 simple type in each file, & letting a folder keep it all together. Advantage is any suitable app can edit specific components. Apple used to use resource forks with ResEdit, now they want all to use the hidden folder approach. Much much easier on tool developers since you reuse what is already out there.

[ Note that the enlightenment foundation libraries ( http://www.enlightenment.org ) goes some way toward making this possible. Combinations of Embryo, Eet and Edje allows this level of customization through "themes" for a single application. ]

Lets make it cooler, you get your components, link them up Cortex style and save them as new processes. Imagine browsing through your Video directory and previewing the video using the folder's background as a screen. The icons maybe will become slightly transparent so that you can see the video a little clearer, but not much because it is - after all - just a preview to see if it's the right document.

Input Kit

• fix the InputServerMethod issues.
• I also have been thinking of moving Joysticks to the input_server.
• allow users to determine the order in which input is passed to the InputServerFilters.
• allow for system wide key bindings
• MIME/Roster
• File types are more human-readable: Document, Image, Video, etc. In our local database we store the MIME translations for those types. Multiple-inheritance is supported, too (Ogg would inherit from audio/ and video/, for example). Instead of specifying attributes for each format individually (MP3 has its own attribute set) the attributes are inherited from the supertype (Audio). Internally, the file types are stored as MIME. This allows for better OS-interoperability, backwards-compatibility, and more flexibility (we can change the inheritance structure of the whole type database and it will continue to work). But there is a problem with this model: global queries (Audio/*) would have to look for multiple MIME-types (application/ogg, audio/*, etc.). Nevertheless, it should be a step forward, usability-wise.
• BClipBoard - ability to have multiple items on the clipboard

Translation Kit

• meta-data (also for file attributes)
• 2D/3D vector graphics
• documents (OpenDocument-based API?)
• spreadsheets
• databases?
• viewers + editors API (like replicants)

Support Kit

• Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

Other

• User preferences USB stick (flash storage) - on boot/disk insertion, check to see if there is a removable volume mounted that has a home directory on it. If so, boot using this as home; allows visiting users to bring their preferences/apps/data with them. Basically a Haiku install minus the system on a flash drive/CD/whatever.
• bundles
• read-only base system (separate partition), read-write overlay system for additional apps, and mobile user profiles (see BSD-HALO)
• collaboration services (multiple persons working on one document over the network )
  
• download_server + API (does this make sense, at all???)
• input profiles?? (mouse, keyboard, joystick?)
• energy profiles

First, let me start out by stating that I use Unix (Solaris) almost every day. While I am not the master of all things Unix, I have a better than average knowledge of it, I like to think. I like a great many things about Unix. Pipes are probably the most useful concept I have ever seen in computer science. It is componentization of software some 20 years before it came into vogue.

While I like Unix, it has some issues, too. Some ideas whose time is past. Some concepts that are outdated and need to be replaced. I believe that foremost among these archaic constructs is /dev.

I can hear the wailing already. Hear me out. For those not initiated in the rites of the acolytes of Bell Labs, /dev is the directory where devices are mounted. So you could look at see /dev/tty for a teletype device. Or /dev/prt for a printer. Back in the days when everything was character based, this was exceptionally powerful. If you wanted to get input from a device, you could do it right from the command line. cat < /dev/foo. Very nice. Or send output to a device - cat tmp.txt > /dev/bar. This has served us well for a very long time, but that time is past.

The first issue that I take with this approach is that most devices are not simple minded printers or modems or teletypes anymore. It doesn't make any sense to say cat < /dev/scanner. Few people want to deal with joysticks, ethernet cards or video cards from the command line in this way. Much of the benefit of making your devices accessible easily from the shell is gone.

Secondly, / is a place for files. Overloading it with devices and other various hardware interfaces doesn't make sense to the average user. Why does it make sense to have a video card in /dev?

Thirdly, from a programmer's point of view, using *only* open, close, read, write and ioctl on devices no longer makes sense. It forces us to funnel every possible command that couldn't be forseen by guys with teletypes to go through ioctl. Think about the act of setting up a scanner for scanning. You end up with code that is very hard to read.

The ioctl commands must be published and (hopefully) standardized. Say you are writing a CD ripper. If one CD Rom's ioctl for "start rip on track 4" is different from a different driver's command, your code must account for that, if you want to work with both devices.

With /dev, you have to know the name of the device that you are interested in. Or, at least, what directory the device driver will publish itself to (yes, that is hard coded). So if you publish an app for, say, MIDI manipulation, you will probably search for /dev/serial1. But what if someone has a /dev/usb/midi/1 device? You can't work with it.

The /dev directory has been filled, too, with "psuedo" devices. The most obvious is /ptty - psuedo tty's for use with PCs. But there are others - kmem (kernel memory) is a good example. This is a nightmare for beginning users.

While I could go on, I have to leave room for the solution to this issue...

BeOS has a wonderful concept called rosters. A roster is basically an "intelligent" keeper of a list. You can use the roster's API questions and it can respond with items or sublists. My concept is a device roster. All devices would have a roster entry that allows you to get one or more device classes back. You can query based on type of data or on device type. For example, you could ask for all devices that can return anything in the mime type "image/". This should return digital cameras, scanners, hard disks, etc. Or you could query for every printer device, etc. All of these devices should derive from a common class (BDevice or some such), but be subclassed (maybe more than once). As an example - a CD ROM drive could be BDevice-->BMassStorage-->BCDRom. This would allow developers some flexability in addressing devices - they could choose to dig deep in the features or they could stay shallow and address more devices.

On a related note, I think that this would open the door to a different type of file panel. How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file?

This system should also make it easier to deal with device configuration. A single application could exist that shows all of the devices. They could be configured via a single GUI, using standardized interfaces.

There are certainly details that would need to be worked out, but I believe that this system would be far more powerful and would shed the legacy pain of /dev.