[xplc-general] discussion on monikers

[Pierre Phaneuf]

Stéphane, remember the stuff I told you about monikers while walking
from work to the Japanese restaurant, a few weeks back? This might
interest apenwarr also, he's quite keen on monikers...

http://primates.ximian.com/~miguel/monikers.html

Note how there is a hiearchy of monikers while resolving them, each
having a pointer to their parent. In COM, one of the things you can ask
a moniker is "what should I add to the stringified moniker to get your
parent", which is something like "/.." for a "file:" moniker, for
example. Something like that.

This makes for a very weird-looking "new:" moniker that they have. It
goes *at the end* (like this: "oafid:RandomFactory:new:"). I think this
makes no sense, but I might just be silly.

Interesting bit of history in section 15...

[Avery Pennarun]

Post by Pierre Phaneuf
http://primates.ximian.com/~miguel/monikers.html
Note how there is a hiearchy of monikers while resolving them, each
having a pointer to their parent. In COM, one of the things you can ask
a moniker is "what should I add to the stringified moniker to get your
parent", which is something like "/.." for a "file:" moniker, for
example. Something like that.
This makes for a very weird-looking "new:" moniker that they have. It
goes *at the end* (like this: "oafid:RandomFactory:new:"). I think this
makes no sense, but I might just be silly.

I guess maybe I'm not understanding what they're doing here, particularly
with the postfix "new:" or the postfix "#gunzip" and "#utar".

Okay, the new: is a bit funky but I can sort of understand: that way you
eliminate the need for a standard IFactory, instead having arbitrary-format
factories whose moniker resolvers know how to do the "new:" appropriately.
This is actually pretty nice, because it means I can do:

IMoniker *x = resolve("wvstreams:tcpfactory");
IWvStream *y = x->resolve("new:1.2.3.4:80");
IWvStream *z = x->resolve("new:2.3.4.5:25");
x->release();

Or alternatively:

IWvStream *y = resolve("wvstreams:tcpfactory:new:1.2.3.4:80");

all at once. Note how this doesn't work with IFactory, since IFactory's
create() doesn't take parameters (making it, as I've mentioned before,
useless to me). They seem to have eliminated IFactory altogether, assuming
that every factory would need different parameters. (Or, to think of it a
different way, assuming IFactory::create needs exactly one parameter - a
string.)

#gunzip and #utar just seem evil to me, however. I don't understand why I
should be able to gunzip a file: moniker but not an http: moniker - or maybe
I can gunzip both, but only if they both implement a parser that will
forward me to gunzip, which is a bit cheesy. gunzip and utar obviously
require a particular interface (VFS of some sort) for the objects they're
passed, but that's fine; have a vfs: moniker namespace or something and use
utar:gunzip:file:/tmp/file.tar.gz and everything should be fine... I think.

(Perhaps this seems so obvious to me because IWvStream is exactly the
interface they wanted for gunzip and utar; maybe if you didn't have
WvStreams, this wouldn't seem so simple.)

Have fun,

Avery