Re: moniker/linking stuff...

[Maciej Stachowiak <mjs eazel com>]

lacage@email.enst.fr (Mathieu Lacage) writes:

> Hi,
> 
> 
> The folowing is a proposal for a Linking architecture in Bonobo.
> 
> 0) details the problems this architecture solves.
> 1) details the CORBA interfaces which we will need to implement.
> 2) details the API developers will have to cope with.
> 

I'm going to ignore all the deep stuff in your proposal (because I'm
not sure I understand the problem you are trying to solve), but I
think it has some problems with basic naming and such.
 
> 1.1) interfaces
> ---------------
> module Bonobo {
> 
> 	/**
> 	 * This interface is inherited by the MonikerFactory
> 	 * object and by the Bonobo::Container Object.
> 	 */
> 	interface ParseDisplayName : Object {

Interface names should be nouns or adjectives, not verbs. Call this
DisplayNameParser. Also, don't you want to inherit from Unknown, not
object (this goes for all the other interfaces, too).

I also don't understand why this interface needs to be separate from
MonikerFactory.

> 		/**
> 		 * parse_display_name:
> 		 *
> 		 * Returns a moniker from the string representation
> 		 * This is probably one of the most important method 
> 		 * here...
> 		 */
> 		Moniker parse_display_name (in string display_name,
> 					    out short display_name_bytes_parsed);
> 	}
> 	
> 
> 
> 	/**
> 	 * The base Factory for all monikers.
> 	 * There should be ONE instance of this
> 	 * object on the system.
> 	 */
> 	interface MonikerFactory : ParseDisplayName {
> 		/**
> 		 * will create an Item Moniker and initializes it with its left moniker
> 		 * and the part of the path it is supposed to represent.
> 		 * Typically, this method would be called with a path set to: "Sheet1" or
> 		 * "A2:A5".
> 		 * a NULL left parameter is valid provided ItemMoniker::set_left_moniker
> 		 * is called after.
> 		 */
> 		Moniker create_item_moniker (in Moniker left, in string path);

What exactly does "left" moniker mean? Is it supposed to be the file
moniker that this item moniker would be a child of? The same goes for
references to "left" in other interfaces.

> 		/**
> 		 * will create a file moniker and initializes it with the path it 
> 		 * represents.
> 		 * Typically, it would be called with the path set to:
> 		 * "file:///home/mathieu/bidule.gnumeric.
> 		 */
> 		Moniker create_file_moniker (in string path);
> 
> 	}
> 
> 	/**
> 	 * This interface is created by calling 
> 	 * one of the MonikerFactory interface methods.
> 	 */
> 	interface Moniker : Object {
> 		exception InterfaceNotFound {
> 			string interface_name;
> 		};
> 	       
> 		exception MissingInterface {
> 			string interface_name;
> 			string object_name;
> 		};
> 
> 		/**
> 		 * bind_to_object:
> 		 * @requested_interface: which interface we want in the end
> 		 *
> 		 * Binds a moniker. Once the service has been registered, it
> 		 * will attempt to get the @requester_interface
> 		 */
> 		Object bind_to_object (in string requested_interface)
> 			raises (InterfaceNotFound, TimeOut, MissingInterface);
> 
> 		/**
> 		 * get_second_moniker:
> 		 * if you are an Item Moniker, you call left->get_second_moniker
> 		 * if you are a File Moniker, you return another File Moniker
> 		 * which is an Absolute File Moniker if the you are a relative 
> 		 * File Moniker. otherwise, if you are an Absolute File Moniker,
> 		 * this returns a relative File Moniker.
> 		 */
> 		Moniker get_second_moniker (void);

This function is badly named and has confusing and complex
semantics. Wouldn't it make more sense to have separate
get_absolute_file_moniker and get_relative_file_moniker calls (which
might just return the object itself?).


> 
> 		/**
> 		 * get_display_name:
> 		 * 
> 		 * Returns a representation of the Moniker
> 		 */
> 		string get_display_name (void);					    
> 	};
> 
> 	interface FileMoniker : Moniker {
> 	}
> 
> 	interface ItemMoniker : Moniker {
> 		boolean set_left_moniker (in Moniker left);
> 	}
> };
> 



> 1.2) interfaces semantics
> -------------------------
> 
> There are 2 levels of Linking support in applications.
> Simple level
> ------------
> 	To support this, application developers must implement a
> 	PersistFile interface.
> 	This will allow users to use links of the kind:
> 	file:///homa/mathieu/bidule.gnumeric but not
> 	file:///homa/mathieu/bidule.gnumeric!Sheet1

file:///homa/mathieu/bidule.gnumeric!Sheet1 really looks like it has
the semantics of a URI reference witha fragment component, but a
different syntax. Is there a reason something like
file:///homa/mathieu/bidule.gnumeric#Sheet1 wouldn't work (other than
excessive MS compatibility)?


I'll leave it to others to comment on whether the design solves the
problems it should.

 - Maciej