- From: Len Bullard <cbullard@hiwaay.net>
- Date: Thu, 20 Mar 1997 12:41:35 -0600
- To: Terry Allen <tallen@sonic.net>
- CC: w3c-sgml-wg@w3.org
Terry Allen wrote: > > What matters is that indirection gets handled, not necessarily which piece > of the machinery handles it. To determine whether it is necessary > to specify which piece of the machinery does the work, you have to > articulate a model of the machinery or of its operations. Literally, you specify the object interface chain you want to use. What you say about the URL processor is relevant. For COM/OLE, you would be using the IMoniker interfaces in right to left order to BindToObject in a chain. To get efficiency, the Running Object Table is consulted as well as the system registry. If a URL moniker is used, a bind context object is used to pass the moniker object a pointer to its client. The URL moniker is asynchronous, of course, to enable the return of data a little at a time and uses a callback. The client creates the moniker by passing the URL to the CreateURLMoniker library function. To initialize, the client calls IPersistMoniker::Load. It passes a pointer to the IMonkiker interface of the URL Moniker. Library functions (MkParseDisplayName and MkParseDisplayNameEx) turn naming strings into monikers. They only know how to locate and run the code that handles a specific type of name. MkParseDisplayNameEx accepts a URL in the form ProgID:Name. The ProgID is a character string translated to a Class ID (CLSID) using the registry. So, to extend the naming code, create the code that handles the naming type and install it with a ProgID and a Class ID for the code. Anyway, that's one way, by the book. len
Received on Thursday, 20 March 1997 13:52:51 UTC