Today the Mercury GUI is tightly integrated with the operating core. When running services you need to unhook a GUI from direct screen calls (such as status windows etc). When David separates the GUI from the core process, there will be methods to create users, aliases, passwords, do restarts, etc by means of hooks into the core, through an API or similar means. Then it is easier to create whatever admin interface that interacts with the core through standardized calls.
The storage of domains etc, is to make it possible to have multiple installations of Mercury, and multiple domains. Today Mercury is based on a flat structure, but domains and users and aliases actually create a hierarchical structure. We have it organized this way today, but I never made a public software for it. A relational sql-database is perfect for this type of structure. Then it is very little effort to take the info to the flat file structure that Mercury is based on.
<P>Today the Mercury GUI is tightly integrated with the operating core. When running services you need to unhook a GUI from direct screen calls (such as status windows etc). When David separates the GUI from the core process, there will be methods to create users, aliases, passwords, do restarts, etc by means of hooks into the core, through an API or similar means. Then it is easier to create whatever admin interface that interacts with the core through standardized calls.</P>
<P>The storage of domains etc, is to make it possible to have multiple installations of Mercury, and multiple domains. Today Mercury is based on a flat structure, but domains and users and aliases actually create a hierarchical structure. We have it organized this way today, but I never made a public software for it. A relational sql-database is perfect for this type of structure. Then it is very little effort to take the info to the flat file structure that Mercury is based on.</P>