You realise that mathematicians, the people who spend far more time writing far more math formulas than any programmer, don't use WYSIWYG tools for writing and editing formulas because it is a pain in the ass.
Good point -- but you should be able to render it that way, because that's the optimal way to read the stuff, which was my main point.
Why would you want translations inside of the source itself?
Because they should be as close to the code as possible.
gettext is a much better solution (you have external message catalogs) because you can edit the message catalogs without recompiling your source.
Manual compilation shouldn't even be necessary. Try a language like Python or Ruby sometime.
It makes a translator's work a lot easier because he doesn't have to understand the language the application is written in and all of the strings are in a central location so he doesn't have to search the program for them.
You're forgetting that with a rich source format, the translator doesn't need to understand the language -- all he needs is an editing tool that can filter out everything except the strings.
It can be the same editor everyone else uses, with filtering built in, or it can be a specialized editor just for translation, which gives you access to spell-checking and dictionary lookup within immediate reach. Or it can be both, with the latter mode as a nice plugin, Eclipse-style.
Because the source is a loose structure, a tool like that can easily let you view and edit just the strings, but still preserve all the other code when the module is saved.
Similarly, the tool can easily find all strings in all modules across a project.
Consider that once you have a richer source format, you can have multiple views on the same data. For example, instead of writing a static documentation generator, Doxygen/Javadoc-style, you can have a view that simply shows you the documentation parts of the source -- filtered dynamically and always up to date. (Python's command-line shell already does this; Ruby's rdoc is similar.)
I believe the term you are looking for is "code generators", not languages. Inkscape and Sodipodi generate XML code, but they aren't languages - they are just tools for drawing pictures. Similarly with Delphi, except in that case the pictures are ugly pieces of Win32 API.
Not at all. Delphi stores visual UIs in a separate format. It doesn't actually generate any code -- the visual representation references methods in your code (eg., "onclick" handlers), and your code can reference and interact with the visual representation. It's MVC.
Similarly, Delphi supports non-visual components that are edited visually. For example, a database connection is created by dropping it in a form. You then link visual controls such as tables and edit fields to the data source. All of this is done visually.
Delphi also has a thing that looks like a form, but isn't rendered at runtime. In other words, a visual code editor -- components are represented as icons you can drag around, link to other components, etc. It's more limited than a full-fledged visual code editor, but still very powerful.
As for inserting images and other documentation into your code - just use doxygen or any other documentation-generation system that compiles your commented source code and external resources into a pretty html / pdf / dvi / whatever document.
I suggest reading up on Knuth's literate programming system, and you'll see how your above comment is something of a non sequitur.
For "proper mathematical notation", you might want to look at Mathematica
That's the whole point -- I don't! Because Mathematica won't conveniently let me do all the other stuff I want.
But all other current computer languages have a pared-down, poor text representation of math notation -- why shouldn't an IDE be able to render that as nicely-formatted, WYSIWYG, directly-editable formulas? There's no particular reason they can't, really.
The assumption that 1 octet equals 1 character is no longer true. The assumption that 1 character on disk must equal 1 character on your screen is equally untrue. Code-folding text editors demonstrate this exceedingly well.
I blame it on the fact that I can't edit your damn png-infested source code with vim over a choppy laggy text-only ssh connection. You don't always have access to X or some other windowing system.
Yeah, let's immediately go for the most extreme use case! You're thinking deep inside the box here. Who says a "rich source" tool can't be run inside Vim or be its own ncurses-based app?
I bet you use MySQL or some other database. You're not editing the data by hex-editing the tables, are you? You're using "mysql" or "psql" as a front end. They work fine in a text-only SSH environment. It's all about having appropriate tools. Why should source code be special?
What's coming isn't languages where you edit XML -- because XML has too much syntactic overhead -- but languages which aren't text based -- languages like Subtext (the screencast demo is essential).
Languages need to evolve out of the pure text medium. This has been happening as incremental hacks to classic languages through code folding editors and AST-aware, intelligent IDEs like Eclipse, literate programming and Python's doctest module. High-level development tools like Delphi were early adopters of the philosophy that code doesn't need to be visualized as text when it's better to visualize it graphically.
The next step is to store not text but structure. For example, why shouldn't I be able to comment on -- annotate -- a specific number in a mathematic formula in my code? With current text-based languages this would be a headache:
Instead, I could just select the value in my editor, click on the annotate key, and enter (in nice WYSIWYG HTML or whatever) my comment there. As a result, the editor will show a tiny icon next to the number, or perhaps in the margin, indicating that there's an annotation.
And why are formulas like that represented with such a poor syntax? Why can't I easily use proper Greek letters and standard math notations such as dots for multiplication, a horizontal line for divisions/fractions, etc.? Why can't I insert images into the source file which illustrate the concept it implements?
What I'm talking about isn't just "rich source code", which Donald Knuth's literate programming concept covers to some extent. Languages will experience a revolutionary leap when they start treating language elements as flexible blocks of content as opposed to tokens in an AST. Consider internationalization; instead of looking up a string from a language-specific message table, your source code can include the string in every possible language, hidden away in a single visual representation -- it might look something like:
showDialog("File not found" [English, Swedish, (8 more languages)]);
where "English..." is a link that opens up a nice GUI letting you change the strings in different languages. The logic to select the string to choose at runtime exists in the string "component" itself.
A common problem in dynamically-typed language is that it's hard to implement optional static typing at the language level. It adds a lot of noisy syntax, and unless you add a lot of syntax, it's hard to solve many ambiguities and special cases. With a rich source format, you can hide away the details, similar to my annotation example.
Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text. Instead, you add intelligence and convenience to your tools. You don't edit your PNG files with Vi -- you use a tool like GIMP or Photoshop.
So all the applications in your system goes through a shared generator which manages a persistent counter?
Do you fsync on every count? How do you guarantee the state of the on-disk counter?
How do you provide this generator to all the languages and platforms that need it, some of which can't realistically make calls to your C library?
How do you license your generator?
The DCE algorithm doesn't need state, and it can be implemented anywhere without interfering with anyone. All DCE UUIDs are unique against all other DCE UUIDs.
The UUID algorithm is mathematically guaranteed. It does account for backward-shifting clocks.
I don't know the details, but I believe that at that time, Microsoft were still on IBM's team developing OS/2. Windows and OS/2 are very similar. Also, both SOM and COM were inspired by CORBA. And there are many differences; COM used DCE-RPC and added UUIDs to interfaces, for example, whereas SOM relied on simple names.
What these technologies had in common was that they implemented binary interface compatibility between components, in a way that seemed to be the wave of the future. But nobody except the CORBA people wanted to standardize the system, and then HTTP came, Microsoft discovered the Internet, and with the XML/SOAP/web services hype people lost focus. COM and CORBA works, and they work extremely well up to a certain point, but they are, ironically, too monolithic, too complex, too binary, too closed-up to integrate into the "Internet ecosystem".
So we no longer have any kind of component object model, which is why we now have XML-RPC, SOAP, RMI,.NET, Python/Twisted's Perspective Broker, Ruby/drb, and lots of other home-grown ad-hoc glue, with the W3C web services effort pretty much the only semi-visionary grab at distributed communication.
No, DCOM is distributed COM, not identical to COM, but a superset.
In theory, yes; that'd be the case if we were talking about something like a standard. In reality, there's only a single implementation of COM, which today includes the distributed object support; it's all DCOM now.
That sounds impressive until you realise that you can simply use the MAC address instead.
The MAC address is a single unique identifier. A UUID is a space of unique identifiers -- it's a product of the MAC address, the clock, a random seed, etc. You generate UUIDs; you can't generate new MAC addresses.
Microsoft's RPC framework, which is built into Windows, is actually an implementation of DCE. While it's a long time since Microsoft used it directly, it's a nice platform for remote communication; it's a mature API that supports a wide variety of protocols (eg., TCP, UDP, local pipes), authentication mechanisms, marshaling mechanisms etc.
Microsoft's COM (also known as DCOM) sits on top of this RPC layer to implement a distributed component object model -- one of Microsoft's finest and most underrated inventions. It's also one of their most copied technologies -- KDE, GNOME, OpenOffice (UNO) and Mozilla (XPCOM) all implement very similar object models.
Of course, DCE RPC is also famous for the UUID (aka GUID) algorithm -- 128-bit identifiers whose uniqueness is mathematically guaranteed as long as the generator can access a network card with a unique MAC address.
Because most people aren't intimately familiar with genetic algorithms, and because GAs are associated with machine learning/artificial intelligence, GAs are seen as somewhat mysterious and magical, and are therefore either accepted with "whoa, cool!" or rejected with "whoa, complex!" While GAs are indeed novel compared to many long-established algorithms, both mentalities are overreactions.
In reality, the basic GA framework is "just" another efficient search algorithm, no cooler or more complex than, say, a hash table or a binary search tree; at its simplest, a GA is a way to find an optimal configuration of components without looking at all possible (potentially explosively exponential) combinations; instead, you look at just some permutations, and as you iterate through generations, applying breeding and mutation, you arrive at a generation which is statistically close to optimal.
GAs are also in no way new or unproven technology; a nice example of mainstream use is PostgreSQL's query planner, which uses GAs to optimize query plans.
I tend to want to buy a lot more stuff than I can afford. So I add books and other items to my shopping carts, such as at Amazon. My Amazon UK shopping cart has more than a hundred items, all of which I intend to buy at some point.
Unfortunately, Amazon's shopping cart is painful to browse when it reaches that size. Also, Amazon distinguishes between the current cart and items "saved for later", and moving between them is also awkward. There's also no way to move an item from my UK shopping cart to the Amazon.com shopping cart, for example.
Recently, I started tagging items with del.icio.us instead of adding them to the shopping cart. Voilà -- a portable shopping cart.
Since I can get the RSS for a collection of tags, I can now easily have a bookmarklet or script that, given a tag, adds each item (based on its ISBN) to a shopping cart -- any shopping cart, not necessarily Amazon's.
Take it one step further: Have a script that looks for the cheapest stores based on the items in the RSS. This assumes the URL contains the ISBN and the script knows how to find it, but that's easy.
Use the same code for the start-up sequence of your program as you do for crash recovery - treat them the same. Fewer lines of code leads to less chance of an error. That's all.
Not just that -- accept that crashing is a valid way of shutting down your program. In other words, be kill -9-safe. Also, include crash recovery in the first place; an orphaned pid file (hello, Jabberd!) or an orphaned lock file (yo, Lucene!) should not prevent a program from starting up. It's incredible how prevalent these little rough edges are.
Crash-only programs crash safely and recover quickly. There is only one way to stop such software -- by crashing it -- and only one way to bring it up -- by initiating recovery. Crash-only systems are built from crash-only components, and the use of transparent component-level retries hides intra-system component crashes from end users. In this paper we advocate a crash-only design for Internet systems, showing that it can lead to more reliable, predictable code and faster, more effective recovery. We present ideas on how to build such crash-only Internet services, taking successful techniques to their logical extreme.
How is this any different from the Windows registry, one of it's most hated "features"?
Not a whole lot. Elektra's essential improvement over the Windows registry is that Elektra is inherently text-based. They also provide a console program that lets you programmatically access the database, either interactively or from scripts, which is a nice touch that avoids the binary opacity of the registry.
Aside from that, Elektra suffers from the exact same problems as the registry. The main problem with this sort of hierarchical key/value database -- and that's what it is -- is that it's just a mass of data, inherently structured but semantically shapeless; the context of any key/value pair is the parent node, and the context of any node is its parent node. As such, it's no better or worse than a bunch of files in a file system.
The reason the Windows registry is such a mess is precisely because anyone can do anything to it. Delete an application and its data remains. Delete the files belonging to a COM component, and its registration information will still be there, and things like context menu entries will be dead ends pointing into the thin air. Even if you're a careful gardener, the registry grows indefinitely.
Even a good package system like APT leaves files behind in/etc. You might say that, without constant weeding, even/etc grows indefinitely. It just grows much slower, and is comparatively easy to keep in shape due to its much simpler structure.
The problem, then, is not the registry's binary nature, nor its weak hierarchical model, nor the lack of scripting tools (although the latter impairs its usefulness). It is that there's no glue between the owner of the information and the information itself; the ideal situation, a registry with no orphaned information, is architecturally not a bad design.
Instead of a single monolithic database, I suggest an aggregated database. Install a piece of software Foo into/usr and its database goes into/etc/foo, then mount it logically under a well-known named node. Thus the "registry", or whatever you call it, is the product of all known sub-registries. Delete an app, and its database can go away as well.
As a personal side note, I think the hierchical, shapeless key/value database design is an incredibly inelegant kludge. People are still blatantly ignoring (and misunderstanding) the best theoretical model for information storage ever invented, Codd's relational model, which is also pretty much the only theoretical model invented.
Fortunately, some people "get" it; the relational nature of RDF triples is one such recent example, and I would rather see RDF (although not necessarily its XML syntax) adopted, because it's such a simple, elegant, extensible system.
What you need is appendItem and friends, or such methods as "insertItemAt", "insertBefore" and "removeAllItems" for the menulist element, along with addEventListener.
Alas, menulist has nothing to do with menus. Correct me if I'm wrong, but I believe menulist is the XUL equivalent of HTML select dropdowns; the elements used for window menus are menu, menubar, menuitem and so on.
I'm starting to figure out how to do this with XUL in-memory datasources now, though; see the first example on this page.
Why the microkernel part? Although I don't have much experience in this, I'd say it should be quite simple, relatively speaking. Look at Linux, most of the kernel tree is drivers. The kernel itself is pretty small.
The Linux kernel actually implements a good compromise, which is to allow kernel modules to be plugged in and out, which is one of ideas behind microkernels. However, there are still user-facing problems with this approach that could be cured without going the microkernel route.
For example, Linux does not provide stable binary interfaces between the kernel and modules, so you can't just plug in any driver -- it has to be compiled against your kernel. This is a political decision; Linus does not want binary drivers. A solution would be something like a source driver package that the driver manager GUI could access and transparently compile; but this, or any other solution, would require the Linux developers to put some thought into kernel user-friendliness, and that is not their strong suit by any means.
The other issue is that of security. At the moment, device driver loading and file-system mounting are superuser operations, but they shouldn't need to be. (User-friendly security in general is one of Linux/Unix' weakest points.)
Btw, I believe the argument that microkernels are inherently slow has been shot down.
Of course, there are plenty of good scripting of languages for Unix. The question is whether we need some higher-level glue between scriptable components, and I think we do.
Try performing file-system-level backups of a Unix system without being superuser. You can't -- there's no way to set up a user that has read/execute access to everything but write access to nothing.
The XUL/Mozilla/Firefox documentation is scattered all over the place. You survive on bits and pieces, little tutorials someone cooked up on their own time, the Mozilla reference, existing extensions, etc. Documentation is often written for the old Mozilla suite, and thus out of date with respect to, say, Firefox' new extension-loading conventions.
What I want to know, which nobody seems to document, is how to create menus dynamically in Firefox. Instead of specifying the menus statically in XML, I want to create them at runtime -- specifically, I want to create a top-level menu item and populate its submenu at runtime based on HTTP queries or something similar. I know it's possible, but I have not figured out how.
Slashdot Mirror
Good point -- but you should be able to render it that way, because that's the optimal way to read the stuff, which was my main point.
Because they should be as close to the code as possible.
Manual compilation shouldn't even be necessary. Try a language like Python or Ruby sometime.
You're forgetting that with a rich source format, the translator doesn't need to understand the language -- all he needs is an editing tool that can filter out everything except the strings.
It can be the same editor everyone else uses, with filtering built in, or it can be a specialized editor just for translation, which gives you access to spell-checking and dictionary lookup within immediate reach. Or it can be both, with the latter mode as a nice plugin, Eclipse-style.
Because the source is a loose structure, a tool like that can easily let you view and edit just the strings, but still preserve all the other code when the module is saved.
Similarly, the tool can easily find all strings in all modules across a project.
Consider that once you have a richer source format, you can have multiple views on the same data. For example, instead of writing a static documentation generator, Doxygen/Javadoc-style, you can have a view that simply shows you the documentation parts of the source -- filtered dynamically and always up to date. (Python's command-line shell already does this; Ruby's rdoc is similar.)
Who said it was limited to the mouse? Select text with Shift and arrow keys, hit Ctrl+A or whatever, enter comment. It's potentially less typing.
Not at all. Delphi stores visual UIs in a separate format. It doesn't actually generate any code -- the visual representation references methods in your code (eg., "onclick" handlers), and your code can reference and interact with the visual representation. It's MVC.
Similarly, Delphi supports non-visual components that are edited visually. For example, a database connection is created by dropping it in a form. You then link visual controls such as tables and edit fields to the data source. All of this is done visually.
Delphi also has a thing that looks like a form, but isn't rendered at runtime. In other words, a visual code editor -- components are represented as icons you can drag around, link to other components, etc. It's more limited than a full-fledged visual code editor, but still very powerful.
I suggest reading up on Knuth's literate programming system, and you'll see how your above comment is something of a non sequitur.
That's the whole point -- I don't! Because Mathematica won't conveniently let me do all the other stuff I want.
But all other current computer languages have a pared-down, poor text representation of math notation -- why shouldn't an IDE be able to render that as nicely-formatted, WYSIWYG, directly-editable formulas? There's no particular reason they can't, really.
The assumption that 1 octet equals 1 character is no longer true. The assumption that 1 character on disk must equal 1 character on your screen is equally untrue. Code-folding text editors demonstrate this exceedingly well.
Yeah, let's immediately go for the most extreme use case! You're thinking deep inside the box here. Who says a "rich source" tool can't be run inside Vim or be its own ncurses-based app?
I bet you use MySQL or some other database. You're not editing the data by hex-editing the tables, are you? You're using "mysql" or "psql" as a front end. They work fine in a text-only SSH environment. It's all about having appropriate tools. Why should source code be special?
Languages need to evolve out of the pure text medium. This has been happening as incremental hacks to classic languages through code folding editors and AST-aware, intelligent IDEs like Eclipse, literate programming and Python's doctest module. High-level development tools like Delphi were early adopters of the philosophy that code doesn't need to be visualized as text when it's better to visualize it graphically.
The next step is to store not text but structure. For example, why shouldn't I be able to comment on -- annotate -- a specific number in a mathematic formula in my code? With current text-based languages this would be a headache:
Instead, I could just select the value in my editor, click on the annotate key, and enter (in nice WYSIWYG HTML or whatever) my comment there. As a result, the editor will show a tiny icon next to the number, or perhaps in the margin, indicating that there's an annotation.
And why are formulas like that represented with such a poor syntax? Why can't I easily use proper Greek letters and standard math notations such as dots for multiplication, a horizontal line for divisions/fractions, etc.? Why can't I insert images into the source file which illustrate the concept it implements?
What I'm talking about isn't just "rich source code", which Donald Knuth's literate programming concept covers to some extent. Languages will experience a revolutionary leap when they start treating language elements as flexible blocks of content as opposed to tokens in an AST. Consider internationalization; instead of looking up a string from a language-specific message table, your source code can include the string in every possible language, hidden away in a single visual representation -- it might look something like:
where "English ..." is a link that opens up a nice GUI letting you change the strings in different languages. The logic to select the string to choose at runtime exists in the string "component" itself.
A common problem in dynamically-typed language is that it's hard to implement optional static typing at the language level. It adds a lot of noisy syntax, and unless you add a lot of syntax, it's hard to solve many ambiguities and special cases. With a rich source format, you can hide away the details, similar to my annotation example.
Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text. Instead, you add intelligence and convenience to your tools. You don't edit your PNG files with Vi -- you use a tool like GIMP or Photoshop.
So all the applications in your system goes through a shared generator which manages a persistent counter?
Do you fsync on every count? How do you guarantee the state of the on-disk counter?
How do you provide this generator to all the languages and platforms that need it, some of which can't realistically make calls to your C library?
How do you license your generator?
The DCE algorithm doesn't need state, and it can be implemented anywhere without interfering with anyone. All DCE UUIDs are unique against all other DCE UUIDs.
The UUID algorithm is mathematically guaranteed. It does account for backward-shifting clocks.
Do the research before you troll.
I don't know the details, but I believe that at that time, Microsoft were still on IBM's team developing OS/2. Windows and OS/2 are very similar. Also, both SOM and COM were inspired by CORBA. And there are many differences; COM used DCE-RPC and added UUIDs to interfaces, for example, whereas SOM relied on simple names.
What these technologies had in common was that they implemented binary interface compatibility between components, in a way that seemed to be the wave of the future. But nobody except the CORBA people wanted to standardize the system, and then HTTP came, Microsoft discovered the Internet, and with the XML/SOAP/web services hype people lost focus. COM and CORBA works, and they work extremely well up to a certain point, but they are, ironically, too monolithic, too complex, too binary, too closed-up to integrate into the "Internet ecosystem".
So we no longer have any kind of component object model, which is why we now have XML-RPC, SOAP, RMI, .NET, Python/Twisted's Perspective Broker, Ruby/drb, and lots of other home-grown ad-hoc glue, with the W3C web services effort pretty much the only semi-visionary grab at distributed communication.
In theory, yes; that'd be the case if we were talking about something like a standard. In reality, there's only a single implementation of COM, which today includes the distributed object support; it's all DCOM now.
That gives you a single identifier. What do you do when you need another one?
The MAC address is a single unique identifier. A UUID is a space of unique identifiers -- it's a product of the MAC address, the clock, a random seed, etc. You generate UUIDs; you can't generate new MAC addresses.
Microsoft's COM (also known as DCOM) sits on top of this RPC layer to implement a distributed component object model -- one of Microsoft's finest and most underrated inventions. It's also one of their most copied technologies -- KDE, GNOME, OpenOffice (UNO) and Mozilla (XPCOM) all implement very similar object models.
Of course, DCE RPC is also famous for the UUID (aka GUID) algorithm -- 128-bit identifiers whose uniqueness is mathematically guaranteed as long as the generator can access a network card with a unique MAC address.
In reality, the basic GA framework is "just" another efficient search algorithm, no cooler or more complex than, say, a hash table or a binary search tree; at its simplest, a GA is a way to find an optimal configuration of components without looking at all possible (potentially explosively exponential) combinations; instead, you look at just some permutations, and as you iterate through generations, applying breeding and mutation, you arrive at a generation which is statistically close to optimal.
GAs are also in no way new or unproven technology; a nice example of mainstream use is PostgreSQL's query planner, which uses GAs to optimize query plans.
Unfortunately, Amazon's shopping cart is painful to browse when it reaches that size. Also, Amazon distinguishes between the current cart and items "saved for later", and moving between them is also awkward. There's also no way to move an item from my UK shopping cart to the Amazon.com shopping cart, for example.
Recently, I started tagging items with del.icio.us instead of adding them to the shopping cart. Voilà -- a portable shopping cart.
Since I can get the RSS for a collection of tags, I can now easily have a bookmarklet or script that, given a tag, adds each item (based on its ISBN) to a shopping cart -- any shopping cart, not necessarily Amazon's.
Take it one step further: Have a script that looks for the cheapest stores based on the items in the RSS. This assumes the URL contains the ISBN and the script knows how to find it, but that's easy.
Since my portable shopping cart is available for all to see, it doubles as a gift wishlist. I've started a read list, too.
Not just that -- accept that crashing is a valid way of shutting down your program. In other words, be kill -9-safe. Also, include crash recovery in the first place; an orphaned pid file (hello, Jabberd!) or an orphaned lock file (yo, Lucene!) should not prevent a program from starting up. It's incredible how prevalent these little rough edges are.
Try EROS, which implements orthogonal persistence.
Not a whole lot. Elektra's essential improvement over the Windows registry is that Elektra is inherently text-based. They also provide a console program that lets you programmatically access the database, either interactively or from scripts, which is a nice touch that avoids the binary opacity of the registry.
Aside from that, Elektra suffers from the exact same problems as the registry. The main problem with this sort of hierarchical key/value database -- and that's what it is -- is that it's just a mass of data, inherently structured but semantically shapeless; the context of any key/value pair is the parent node, and the context of any node is its parent node. As such, it's no better or worse than a bunch of files in a file system.
The reason the Windows registry is such a mess is precisely because anyone can do anything to it. Delete an application and its data remains. Delete the files belonging to a COM component, and its registration information will still be there, and things like context menu entries will be dead ends pointing into the thin air. Even if you're a careful gardener, the registry grows indefinitely.
Even a good package system like APT leaves files behind in /etc. You might say that, without constant weeding, even /etc grows indefinitely. It just grows much slower, and is comparatively easy to keep in shape due to its much simpler structure.
The problem, then, is not the registry's binary nature, nor its weak hierarchical model, nor the lack of scripting tools (although the latter impairs its usefulness). It is that there's no glue between the owner of the information and the information itself; the ideal situation, a registry with no orphaned information, is architecturally not a bad design.
Instead of a single monolithic database, I suggest an aggregated database. Install a piece of software Foo into /usr and its database goes into /etc/foo, then mount it logically under a well-known named node. Thus the "registry", or whatever you call it, is the product of all known sub-registries. Delete an app, and its database can go away as well.
As a personal side note, I think the hierchical, shapeless key/value database design is an incredibly inelegant kludge. People are still blatantly ignoring (and misunderstanding) the best theoretical model for information storage ever invented, Codd's relational model, which is also pretty much the only theoretical model invented.
Fortunately, some people "get" it; the relational nature of RDF triples is one such recent example, and I would rather see RDF (although not necessarily its XML syntax) adopted, because it's such a simple, elegant, extensible system.
You will want Ted's Extension Developer extension if you're going to develop Mozilla (including Firefox/Thunderbird) extensions. Incredibly useful.
Alas, menulist has nothing to do with menus. Correct me if I'm wrong, but I believe menulist is the XUL equivalent of HTML select dropdowns; the elements used for window menus are menu, menubar, menuitem and so on.
I'm starting to figure out how to do this with XUL in-memory datasources now, though; see the first example on this page.
The Linux kernel actually implements a good compromise, which is to allow kernel modules to be plugged in and out, which is one of ideas behind microkernels. However, there are still user-facing problems with this approach that could be cured without going the microkernel route.
For example, Linux does not provide stable binary interfaces between the kernel and modules, so you can't just plug in any driver -- it has to be compiled against your kernel. This is a political decision; Linus does not want binary drivers. A solution would be something like a source driver package that the driver manager GUI could access and transparently compile; but this, or any other solution, would require the Linux developers to put some thought into kernel user-friendliness, and that is not their strong suit by any means.
The other issue is that of security. At the moment, device driver loading and file-system mounting are superuser operations, but they shouldn't need to be. (User-friendly security in general is one of Linux/Unix' weakest points.)
Btw, I believe the argument that microkernels are inherently slow has been shot down.
Unix needs something like MSH, I think.
Of course, there are plenty of good scripting of languages for Unix. The question is whether we need some higher-level glue between scriptable components, and I think we do.
Try performing file-system-level backups of a Unix system without being superuser. You can't -- there's no way to set up a user that has read/execute access to everything but write access to nothing.
Thanks, I already knew about it. But it doesn't provide all the pieces of the puzzle.
Apparently XUL templates is the way to go, but I don't know how to supply the datasource implemented with JavaScript.
What I want to know, which nobody seems to document, is how to create menus dynamically in Firefox. Instead of specifying the menus statically in XML, I want to create them at runtime -- specifically, I want to create a top-level menu item and populate its submenu at runtime based on HTTP queries or something similar. I know it's possible, but I have not figured out how.