1. What is registrar?

This would be a helpful paragraph. MurrayCumming

2. Why registrar?

1. You can take the storage structure of what is being installed out of the compatibility equation. All you guarentee

• is that the registrar will be able to input some particular file type and all of the details of how and where it installs it are not guarenteed but belong to the registrar. In the simplest scenario a very simple registrar could just be something that copies files to predefined locations. However, it gives the option that it could automatically arrange icon themes in an mmap'able form, put menu files into some kind of database, etc ...

2. Installs would be declarative rather than programmatic which makes possible things like finer grained security and

• the registrar could be optionally enhanced with special knowledge to do particular things (ie. filters) without breaking client installs or GNOME library backends. ie. registrar --register application.registration --scope=USER to install an application for just one user or all distro-specific file location changes are irrelevant ie. registrar --register browser-plugin.registration puts the plugins in the appropriate browser(s) plugin folders

3. The files that the registrar can read should be standardized and made nice because they will be the compability criteria. If

• this was something like XML we could do something like:

<registration

• xmlns="//freesystem.org/1/component"
  xmlns:app="//freedesktop.org/1/app"
  xmlns:mime="//freedesktop.org/1/mime"
  xmlns:doc="//freedesktop.org/1/doc"
  xmlns:icons="//freedesktop.org/1/icons"
  xmlns:po="//freedesktop.org/1/translations/po"
  registration-id="3434-SOME-2984-UNIQ-UE34-GUID"
  >

  <component>
  

  • <app:app>
    

    • <app:name></app:name>
      <app:version></app:version>

      <mime:mime-types>
      </mime:mime-types>

      <app:actions>
      

      • <app:configure></app:configure>
        

      </app:actions>

      <collection>
      

      • <doc:documents>
        </doc:documents>
        

      </collection>
      

    </app:app>
    

  </component>
  

</registration>

• The registrar would have an extensible backend with each backend registering its own XML namespace and handling all of the registration for that namespace. The absolute minimum registrar code would just know of unique GUIDs and things like components, pieces, collections and relationships.

4. This gives us more information. So that we do treat more things as top-level objects because we have more metadata

• connecting things together.
• An APPLICATION object could have a namespace where the application registers
  • common actions on the application: run, uninstall, help, or configure. We can then do things to applications. Or a hypothetical menu editor could give details on the currently selected application: ie. links to documentation, what languages it is translated in, what MIME types it handles, etc ...
• Or an application could register some processes for automatic session startup and the GUI would then have
  • enough information to be able to give nice descriptions and details on which application added a startup process rather than showing a command-line "eds-slay-memory-bonobo-restart --ior=2934839834"...
• Or in application uninstallation. Removing this application will remove support for these MIME types, this
  • web browser plug-in, etc ...

5. The registrar would have a very limited set of commands: maybe registrar, query, check, & unregister. Each registrar

• backend would implement each command and handle the command for its namespace.
• registrar does the installation,
• query should be a simple namespaced, property=value mechanism. Backends could store these properties or generate them on-the-fly from some place else they just need to be able to answer a query.
• check is a query that just returns yes/no the thing your query asked about is there or it isn't.
• unregister unregisters based on some kind of component ID. An on-the-fly generation of properties example could be a C library namespace (c:) which details all of the installed C libraries on the system. It could handle a limited set of properties (ie. name, version, path) and get this information by stating /usr/lib, /usr/local/lib, etc ... So there is no one master registry backend that contains the state of the entire computer (well actually that would be an implementation detail). Instead we standardize the interface to the registrar and the backends do what is appropriate for them. An initial C library backend could be what I said or it could be extended so that it subsumes all of the functionality of pkg-config. Whether or not to remove pkg-config at that point is entirely optional since the C library backend of registrar could read the information directly from installed pkg-config files. The registrar interface is available through libregistrar so applications can discover information about their own configuration by linking with this library (just glibc and d-bus dependency on Linux with registry interface on Windows?). ie. GIMP could install a "gimp-plugin" backend to the registrar. Then every GIMP plugin registers with this backend. Then GIMP can query the gimp-plugin backend through the registrar to determine what is installed. This is good for the GIMP and this is good for administration because all of the major pieces of the system can be seen through a single interface. Plug-ins are good example because they are typically much smaller than packages and some do an end-run around the packaging system. ie. perl modules from CSPAN, eclipse plug-ins. These would be seen by the registrar (if it had the appropriate backend) but would not be seen from RPM. We also have more useful OBJECTS than just PACKAGES.

  SeanMiddleditch: There should also be an 'update' command for apps like Mozilla, where components would have to be reinstalled/symlinked after a new version of the app is installed. This will be useful because, as mentioned below, many frameworks and applications won't be using the registrary library for some time.

6. This can easily be applied lower down the stack at the system level if it works well. ie. treat services

• as objects that you can register information on like name, vendor, version, dependencies, ports its using, directories it will write to, where its log files are written to, etc ... this can be used for many purposes including service ordering at startup, having a SERVICE object for administrators and bringing together information that would be necessary to write SELinux policies.

3. Possibile candidates from the freedesktop/GNOME world

• application information (it should not be a menu entry but instead provide application details which can be presented in menu form)

• MIME types & actions

• icon themes
• documentation
• translations
• other resources
• d-bus session processes
• applets
• notification are
• gconf schemas
• nautilus extensions:
  • context menu additions
  • property page additions
  • thumbnailers
• browser plug-ins
• pango shaper engines / language engines
• spelling dictionaries
• gdk-pixbuf backends
• gstreamer codecs
• keyboard maps
• fonts
• stock application type (ie. word processer, e-mail, editor)
• gnome-vfs backend
• bonobo IDLs

4. Possible candidates from system world (to complete the thought)

• c library
• c++ library
• java package
• mono assembly
• perl module
• python module
• service
• man page
• desktop environment
• hardware driver
• apache module
• postgresql pl/sql language
• package

REMEMBER None of this would require changes to any of this stuff since all we initially need to do is add in the abstraction that the register will put things where they belong, even if that is exactly where they currently go.

SeanMiddleditch: I really love this idea. It's something I've been toying with for a few months now, but on a much grander scale. The really interesting part is that this is really only a step or two away from being a whole new package manager. I wonder how well it would work with things like RPM, where it simply drops in a bunch of files and then runs scripts - the package manager would need support for temporary files that it unpacks, then lets post-install script run through the registrar. Or, better yet, direct support for the registrar so packagers don't have to do all the registrar invoking and error checking by hand in a script for every package. It's something that existing package formats can use right now with some scripting work (which would continue working in the future) and that updated or new formats can make special use of. A registrar system is, I think, pretty essential to the idea of having a rock solid developer friendly application platform.

AlexGraveley: I like this idea also, but I wonder how it is different from the autopackage.org project, which seems to be functional today. Also, I wonder about how non-monolithic (mono or java) apps might work: ones that can package all their needed resources/files into a single .exe or .jar. I would really like to see support for having these sorts of apps package all the registrar-installed files internally, and just dropping them into a blessed directory would registrar/autopackage-install them.

SeanMiddleditch: AutoPackage is not at all related to this problem. First, AutoPackage is an actual packaging format, while this registrar is a mechanism to be used by a packaging format. For example, RPMs (which are going to exist for a long time yet) could use this registrar system, while they can't use anything inside of AutoPackage. Also keep in mind that AutoPackage is Linux-only, and x86-only at that (for now). A registrar would also work for source installs, custom installers, all packaging formats (even rarely used odd-ball ones), and so on.