how about a registry

Coming from a Windows background, the word "registry" scares the hell out of me. It's scarred me for life.

/me huddles in corner

But seriously, I have no idea :P How BeOS did it will probably have to be the way for R1, for backwards compatability, but after that?

A registry IMO is a bad idea, with Windows being the primary example. Windows needs to be reinstalled every so often because the registry gets bloated. With the increase in size comes slower lookups and, thus, system slowdown. IIRC, it was designed to solve the problems Windows had with storing configuration data and settings. We don't have that problem because we have a semi-definite idea of where things should go.

Interprocess communication is already taken care of -- the API already handles this in a very elegant way.

Linux runs into most of its problems because there is no real unified effort to make it all work together in a cohesive way, unlike Haiku.

This is Haiku's major selling point for me. I like Linux (Debian in my case) a lot, but sometimes it just feels very cobbled together. I'm hoping that Haiku won't have that problem.

I agree. I would be very sad if any other OS EVER tries to use a registry. It really makes very little sense with all of the other less convoluted alternatives.

The exchange of information is often made over complicated — moving data can be don't very elegantly with flat files — linux, os x, and other handle it quite well. The reason windows used it was because they don't figure out that flat files should be stored centrally (or at least logically). Granted, A FEW VERY CHOICE, LIMITED things, like users, groups, and aliases would be acceptable in a database. But it shouldn't even be called a registry. Preference files are more efficient, less bloating to the system ,easier to access and maintain, and more open.

That is the question. I think there ought to be a SYSTEM registry with read-only access for apps. But a registry for apps, no way.

Too often I have found that apps use the registry to hide things, or use it as temporary storage for run-time values. The most annoying and troublesome factor I have encountered with registry use is during an uninstall.

More times than not, an uninstall, which is dependent on an app's install log as well as an app's uninstall routine, fails to eliminate all traces of an app's presence. This is due to an app failing to record all installed elements, whether from the initial install, updates or run-time.

Although apps may proliferate their details throughout a system, not just the registy, the registry is the most difficult location from which to eliminate left-overs.

I think you missed the point. Linux uses all kinds of RPM/yum/etc installation tree logging and the whole stupid /etc/ directory as its its registry. It's a convoluted, disorganized mess. The Windows registry, despite being "wrapped" in a container file, gets really messy, as well, particularly where COM objects and proprietary registrations are "documented". However, there are elements of the Windows registry that are very interesting and ideal. For example, if the registry was not abused by Microsoft, it would be about 1/500th the size that it is in a complete Windows Vista 64-bit installation with Windows SDK, MS Office, and Visual Studio installed. That small, unbloated registry would be a hugely helpful resource for managing system settings in one place.

I personally love the Microsoft Windows registry. I hate Microsoft's bloat-junk, but I love knowing that I can go straight to HKCU/Software/{App}/@appsetting=value to tweak some obvious setting, all in one place, and I don't have to worry about some .ini file or .config file or some proprietary setting file, or worst of all a binary one. And with PowerShell I can traverse the registry not unlike Linux users traverse /etc/, so handiness of calling up some editor from a path to reconfigure something doesn't necessarily mean losing out on quick and terse console commands.

I'd love to see the Windows registry idea applied with Be / Haiku's clean, terse, and sensible naming and path convention applied to it.

My $0.02.

jon

I just took a peek at elektra. I think Eletrka is a fantastic idea for Linux, and the concept of a clean and unified configuration system is one that any modern and clean operating system should strive for. (Just don't abuse it like Microsoft does.)

I wanted to expand on this thought. I already stated I think standardizing and consolidating integration configuration with a common store, API, and interface is important for a proper, modern OS. Not to mention, as I previously noted, having a consistent configuration store / API / interface gives users of all levels the ability to go in and change both system and application settings in one place.

The reason why there is a registry for Windows is because there are so many apps that actually integrate with the operating system--having a consistent uninstall path for end users (Add/Remove Programs control panel), adding file type icons and MIME types (yes, Be/Haiku has its own API for this), having the ability to load up an OS-registered COM server by CLSID (a GUID) or by name (Haiku doesn't support COM so this is moot), having shell extensions so that you can do things like right-click an icon and special context menu options show up, etc. But I agree that putting EVERYTHING in the Registry as Microsoft makes a habit of doing is just stupid, particularly if it is spaghetti where dependency settings are left unmapped and undocumented.

Secondly, I am as disgusted as everyone else with the mess that the Windows Registry has become. But I really don't think that the problem is the presence of the registry itself. I think the problem is inadequate standards and crappy structure design. For example, if an installed app MUST put its installation log into the registry, it should be forked in an "Installations" branch that someone doing a manual uninstall should be able to just right-click "Installations/MyApp" and choose "Delete", and then all of the setup-related information is removed. Shared libraries should be the same, and not accessed solely through a GUID (I HATE trying to find GUID-ified registry keys!!). Figuring out how to completely manually uninstall a corrupted Windows component installation takes me a couple hours of searching values that contain the old file path, and then I have to delete one randomly generated GUID named registry branch after another, at least a hundred times, before Windows itself will acknowledge that the thing isn't installed.

So in other words, the suggestion of a registry also infers a suggestion of a halfway decent structure / design, unlike the mess that the Windows registry is. Get the structures cleanly designed and standardize on it, and then most of the arguments against the registry become moot.

As for the arguments about having one big, bloated file managing configurations, that will break the OS if the one file gets corrupted, I would argue that that's what makes it reliable. Build the store accessor on SQLLite or something, do transactional logging, and make regular backups. It's much more of a pain in the neck to restore broken RPM history chains, and config files inside individual app directories don't befit OS integration requirements, nor, for that matter, consistency in the real user experience.

On the other hand, if the OP (original post) was more along the lines of inter-process communication, using the registry for that is abuse. That's not what a registry is for. The registry is just a database for the local computer for persisting configuration data, not for memory swappage from one app to another.

Does anyone here remember how old BeOS handled the tasks that are proposed for the Haiku and registry?

I personally like more gconf like approach. I can use special utility (like a regedit eg gconf-editor, 'tho i don't like that they chose .xml for gconf, there's nothing wrong with plaintext and 'Keep It Simple,Stupid - KISS') and i can browse it with any filemanager or from plain old shell...

btw, imho a regular BeOS filesystem IS structured, hierarchical and searchable, so why re-invent the wheel? and BeoS had an AMAZING filesystem, imho. and with all the journaling (i think it was journaling?) and all the attributes, it was all tested and working - why not use that (approach)?

maybe: just 1 folder - config (?), and in that 0-byte files named after the owner-application and all these files have attached attributes which are the configuration information - keys and values. simple, imho. and ANY tracker window can become a 'regedit'.

-config (folder)
|-hterm (file=application name)
| \-window.width=1000 (attributes=keys and values)
| \-window.height=700
|
|-foobarN
| \-parameter=X

etc

those keys and values could be also INSIDE those files, but then there's always the question of linefeeds, case, formatting etc and one would need to use a text editor.

most of the times more is less, more or less...

~~~~~~~~
I like your Christ, I do not like your Christians. Your Christians are so unlike your Christ.
Mahatma Gandhi

I like the BeOS way. Settings are in /boot/home/config/settings. If you need to remove a program, delete the app - usually in /boot/apps - or wherever you placed it and remove the settings from /boot/home/config/settings. say you installed Opera ... it installs in /boot/apps/Opera and adds /boot/home/config/settings/Opera. jsut delete these two folders and the program is removed. This is what the uninstaller in /boot/apps/Opera does. No REGISTRY PLEASE !!! we all hate REGISTRY SETTINGS.

A registry, as a database which is loaded each time the system starts, is obviously a bad idea. But it will be nice if Haiku standardizes on 2 locations for storing conf. files : one for the user prefs and one for system wide prefs. I suppose Haiku already does this.

Now, there could be a system API which provides direct and easy access to these settings (think extremely simple calls like store(key, value) and get(key)). The default method of storage can be either XML files, or a small, fast database like SQLite (in that case, a more advanced API might be required to harness the full power of SQLite).

If this API is well designed and works for the most common applications, then it will be taken up by the app devs. For more advanced storage and retrieval of conf. data, the devs can still use their own APIs and methods of storage, but the location for these config. files must be a universal standard (as it is now, AFAIK).

I don't think that anybody will need to do more than store and retrieve simple values from the registry, anyway.

Don't go the Linux way, though, where there has been a severe lack of standards until very recently.