Comparing the Moniker name space with the Unix Name Space

Lets start simple. A moniker is a reference to an object[1]. To actually use the object, you have to "resolve" the moniker. The term used in the literature is "binding the object".

The result of resolving the moniker is a Bonobo::Unknown object.

Think of a moniker as a pathname. And think of the binding process as the "open" system call on Unix.

Example:

In the case of the file system, the kernel does the "resolution" of each path element by parsing one element of the file system, and the Virtual File System switch uses the current file system + mount points to resolve the ultimate file name.

The file moniker

The file moniker is used to reference files. For instance:

file:sales.gnumeric

The file moniker will scan its argument until it reaches the special characters `#' or `!' which indicate the end of the filename.

The file moniker will use the mime type associated with the file to find a component that will handle the file. Once the object handler has been invoked, the Moniker will try to feed the file to the component first through quering the PersistFile interface, and if this is not supported, through the PersistStream interface.

The item moniker

The item moniker is typically triggered by the "!" string in the middle. The item moniker can be used to implement custom object naming, or argument handling.

The item moniker parses the text following '!' until the next '!' character, this is called the argument of the item moniker. During the resolution process, the item moniker will request from its parent the Bonobo/ItemContainer interface and will invoke the getObject on this interface with the argument.

For example, in a Gnumeric spreadsheet this allows programmers to reference sub-objects by name. For instance, Workbooks can locate Sheet objects; Sheets can locate range names, cell names, or cell references.

This moniker would reference the sheet named `Sales' in the workbook contained in the sales.gnumeric spreadsheet:

	sheet = bonobo_get_object ("sales.gnumeric!Sales", "Gnumeric/Sheet");
		

This other would reference the cell that has been named `Total' inside the Sheet "Sales":

	cell = bonobo_get_object ("sales.gnumeric!Sales!Total", "Gnumeric/Cell")
		

The way this works from the container perspective, is that the container will implement the getObject (string) method, and would respond to the getObject request.

Item monikers can also be used to perform instance initialization. The component that wants to support instance initialization needs to support the Bonobo/ItemContainer interface and implement a getObject method that would return the object properly initialized.

For example, lets consider an image viewer component that can be configured, like this:

	image = bonobo_get_object ("file.jpg!convert_to_gray=on", "Bonobo/Control")
		

The above example would activate the EOG component because of the file.jpg match, and then invoke EOG's ItemContainer implementation with the argument "convert_to_gray=on". getObject should return an object (which would be itself) but it would modify the instance data to set the "convert_to_gray" flag to on. Like this:

Bonobo_Unknown
eog_item_container_get_object (BonoboObject *o, char *name)
{
	if (command_is (name, "convert_to_gray", &v))
		image_set_convert_to_gray (o, v);
	...
	bonobo_object_ref (o);
	return bonobo_objet_corba_objref (o);
}
		

The oafiid moniker

The oafid: moniker handles activation using the Object Activation Framework. This allows application programmers to activate objects by their OAF ID, like this:

	gnumeric = bonobo_object_get ("oafiid:GNOME_Gnumeric_Workbook", iface)
		

The "new:" moniker

The new moniker requests from its parent the "Bonobo/GenericFactory" interface and invokes the method create_instance in the interface.

Typically this moniker would be invoked like this:

		bonobo_get_object ("oafid:RandomFactory:new:", iface);
		

In the example above "RandomFactory" is the OAFID for the factory for a certain object. During the resolution process, the "new:" moniker would request its parent to resolve against the IDL:GNOME/ObjectFactory:1.0 interface (which is the traditional factory interface in GNOME for creating new object instances) and then invoke the new_instance method on it.

Historically GNORBA (the old GNOME object activation system) and OAF (the new object activation system) implemented a special "hack" to do this same processing. Basically, the description files for the object activation system was overloaded, there were three types of activation mechanism defined:

The "new:" moniker basically obviates the need for the last step in the activation system. With OAF, using the OAF approach proves to be more useful, as it is possible to query OAF for components that have certain attributes, and the attributes for a factory object are not as interesting as the attributes for the instances themselves. Despite this, the "new:" moniker can be used for performing the operation of instance initialization in more complex scenarios that go beyond the scope of activation provided by OAF.

The Configuration Moniker

The configuration moniker is invoked by using the "config:" prefix. The string afterwards is the configuration locator. The moniker should support being querried against the "Bonobo/Property" or "Bonobo/PropertyBag" depending on whether we are requesting a set of attributes, or a single attribute.

For example, retrieving the configuration information for a specific configuration property in Gnumeric would work like this:

	Bonobo_Property auto_save;
	CORBA_Any value;
	
	auto_save = bonobo_get_object (
		"config:gnumeric/auto-save", "/Bonobo/Property");
	value = bonobo_property_get_value (auto_save, &ev);
	if (value-> tc-> kind == CORBA_tk_bool)
	    printf ("Value: %s\n", (CORBA_bool) value->_value ? "true" : "false");
	else
	    printf ("Property is not boolean\n");
		

In the above example, we first use the bonobo_get_object routine to locate the configuration object through its moniker. The return value from the bonobo_get_object is of type Bonobo_Property which is the standard Bonobo way of manipulating properties.

This has two main advantages:

The Bonobo::Property interface is pretty comprehensive, and should address most needs, the methods are:

	string   get_name ();
	TypeCode get_type ();
	any      get_value ();
	void     set_value ();
	any      get_default ();
	string   get_doc_string ();
	long     get_flags ();
		

Now, this interface as you can see does not specify an implementation for the actual backend. Given that this is just an interface, we do not care what the moniker will connect us to, we only care with the fact that we will be able to use the Property and PropertyBag interfaces.

Configuration transactions

Handling of transactional changes to the configuration system can be achieved by the use of the setValues interface in the PropertyBag. The implementation of the PropertyBag can either accept the values set, or it can do consistency checking of the values being set (for instance, to avoid the configuration to contradict itself, or store invalid values). If the values being set are invalid, an exception is thrown.

It would be also possible to hook up an arbitrary consistency checking component in the middle, by inserting the consistency checking in the middle of the stream, like this:

	bonobo_get_object ("config:gnumeric/auto-save:gnumeric-consistency-check:", "Bonobo/Property");
		

Notice the `gnumeric-consistency-check:' moniker handler. This could just be a shared library consistency checking component if it needs to be.

Listening to changes.

One of the requirements for a modern desktop is to be react globally when changes are made to global settings. For example, in the GNOME desktop when a theme is changed, a special protocol inside Gtk+ is used to notify all the applications that they should reload their theme configuration.

There are many other examples where applications need to keep track of the current setting. For example, when a preference is changed, we want the preference to take place right away, without us having to restart our running applications.

This is easily achieved by registering a Listener with the Bonobo/EventSource in the PropertyBag.

What about GConf?

GConf is a configuration management infrastructure that provides the following features:

There are two drawbacks to GConf currently:

The actual engine and backend for GConf could become the configuration moniker handler, only the API would be replaced as well as the actual storage system to support the more complete CORBA_Any, and the ad-hoc CORBA interface can be replaced with a more powerful system.

Configuration management: Open Issues

Specifying the location for configuration. The syntax for accessing the configuration has not been defined, but we can cook this up pretty easily.

Forcing the configuration data to be loaded from a specific location. Although the arguments to the moniker could be used to encode a specific location, for example:

	config:~/file.config!auto-save
		

It seems more natural to use the file moniker to provide this information, for example:

	file:~/file.config!config:auto-save
		

The config moniker can test for the presence of a parent, and if the parent exists, then it would request one of the Persist interfaces from it to load the actual configuration file, and provide access to it.

Transactional setting of values. It might make sense to "batch" a number of changes done under a prefix to avoid listeners to a range of keys to reset themselves multiple times. Consider the case in which a command line tool makes various changes to the background properties, say the changes are done in this order:

	background = bonobo_get_object ("config:desktop/background", "PropertyBag");
	bonobo_property_bag_set_values (background, 
		bonobo_property_list_new (
			"gradient", "string", "true",
			"color1",   "string"  "red",
			"color2",   "string"  "blue",
			&ev);
		

If the real configuration program for handling the background is running at that point, it will have registered to be notified of changes to all those values. The changes might be very expensive. For example the code migh react to every change and recompute the whole background image on each change.

An optimization would be to tag the beginning of the transaction and the end of it in the client code to allow listeners to get batched notification of changes:

	background = bonobo_get_object ("config:desktop/background", iface);
	bonobo_property_bag_batch_push (background);
	bonobo_property_set (background, "gradient", "true");
	bonobo_property_set (background, "color1", "red");
	bonobo_property_set (background, "color2", "blue");
	bonobo_property_bag_batch_pop (background);
		

This would allow the listener code to batch all the expensive requests into a single pass.

Configuration handlers. Consider the example above, we would like to be able to change properties on the system and have those properties to take effect independently of whether a listener is registered or not.

A property handler might register with the configuration moniker to be launched when a property changes. This could be done in a file installed in a special location.

The GNOME VFS becomes deprecated.

The GNOME VFS provides an asyncronouse file-system interface abstraction that can be used to access local files, remote files, files in compressed files and more.

The problem with the GNOME VFS is that it is very limited: it can only expose a file system like interface to its clients (very much like the Unix interface after which it was modeled).

As covered before in the `Object Naming Space', Monikers define an object naming space, and monikers can be defined for any type of resource that the GNOME VFS supports (a transitional path might include a set of monikers implemented on top of the actual GNOME VFS).

A file dialog could request a moniker to be resolved against a "Graphical File Listing" interface, which might result in a miniature Nautilus window to be embedded in the dialog box.

It would be possible to entirely reuse the existing GNOME VFS code by providing monikers for the various access methods that would handle the special cases "Stream", "Storage" and "FileListing". Other interfaces will be plugged into the moniker handler to support the richer content.

For instance, consider the "trashcan:" moniker. The trashcan moniker could be resolved against various interfaces. A file manager would resolve it against a DirectoryListing interface to display the contents of it; It could resolve it against a "Control" interface to get a trahscan custom view (to configure the values in the trashcan); a PropertyBag interface could be used to programmatically configure the various settings in it.

The streamcache: moniker

The idea of the streamcache: moniker is to be basically a shared library moniker handler that provides a cache for the IDL:Bonobo/Stream:1.0 interface.

This moniker is very simple, during resolution it requests the IDL:Bonobo/Stream:1.0 interface from its parent and it can only expose the IDL:Bonobo/Stream:1.0 interface to clients.

The plus is this: it is a shared library component, which will run in the address space of the application that will use the Stream, and it provides a cache to the parent Stream (so we can use small granular method invocations, and the stream cache can do the traditional buffering).

Think of this difference as the one between an application using write()/read and the application using fwrite/fread/getc/putc: although many applications can implement their own buffering, most of the time just using the libc-provided ones (fwrite/fread/getc/putc) will do it. This is exactly what the streamcache: moniker will do: By appending this to a stringified representation of a moniker, you can get a Stream cache for free.

The #gunzip, #utar filtering monikers

The #utar moniker is a moniker that would implement tar file decoding (the same concept can be used for other archive formats). This moniker uses an auxiliary tar component handler. The moniker connects the tar component handler to the parent object's Stream interface and returns the resulting object. The result of the #utar moniker can be either a Bonobo/Stream (for a file reference) or Bonobo/Storage (for a directory reference).

Like this:

	file:/home/miguel/mail-backup.tar#utar:2000/may/1001
	ftp://ftp.helixcode.com/pub/sources/gnome-libs-1.2.tar.gz#gunzip#utar:/README
		

The beauty of this system is that if two applications use the same moniker, they would be sharing the same data without having to uncompress two times the same tar file.

This is all achieved transparently. This would happen in quite a few instances, for example, if you are exploring a compressed tar file in a file manager and you drag the file to another Moniker-aware application, say Gnumeric, Gnumeric would be using the same file that was openened by the file manager instead of having two uncompressed sets of files in your system.

The above scenario is particularly useful if you have little space, or if the process of untaring a file would take a long time.

The propertycache: moniker

Accessing individual properties over and over might take quite some time due to the CORBA round trips. The propertycache: moniker would be also a shared library handler that would basically activate the property moniker, and would set up property listeners (which would be notified of changes in the property data base).

So if your application does a lot of queries to a property, you might just want to append this to improve performance and not care about doing clustered reads, the cache would do this for you.

This is not implemented, as it requires the property moniker to be written.