Re: monikers in a filemanager.

[monkeyiq <monkeyiq dingoblue net au>]

On 05 Dec 2000 16:30:58 -0500, Michael Meeks wrote:
> 
> Hi there,
> 
> 
>         I would encourage you instead to be integrating FAM with
> gnome-vfs, and providing a nice CORBA interface via a moniker.

Hmm, I will prolly be taking a look at gnome-vfs soon, so I'll keep in
mind how hard
a fam integration would be when I read over gnome-vfs. I dont actually
run nautilus at
the moment, as I am not persistent enough to compile it from cvs on my
rh7 boxen that
already has evolution installed (but thats another story).

> 
>         Ok; with monikers we represent a massive global object namespace,
> whilst I see your point that you would need some sort of base
> configuration to get 'root' type anchor monikers ( such as perhaps
> ) config:/, file:/, smb:\\server\whatever, my_computer:/, desktop:/
> etc. storing each sub-moniker in a file would not be sensible, if that is
> in fact what you suggest ?

Hmm, looking at the above, I don't know if you just plucked the moniker
prefixes out of the air, but
I guess I am file biased, I would surely see file:/ and smb:\\ as being
just a file moniker. I mean I
can see gains in having them seperate, but from an application
developers point of view using the
kernel to automount a samba share and using the smb fs to view it surely
makes the development 
of the filemanager much faster, and I can't see that code that I write
to use smb protocol would be
even close the the quality of existing code (I would prolly get board
with it).

config:/ is a dubious one, esp with gconf around, it would be best to
have a global moniker for this I guess.
but this is a great example of my file based monikers... have a file
that contains "config:/localhost/" on its
one and only line, when read it instructs the fm to create a moniker for
the config data on localhost, and
from this moniker all config data is accessed. This effectively allows a
vfs only fm to show fancy monikers
too. 

The only use of sub monikers would be like creating a soft link or
bookmark to a moniker readable/writeable
section, for example with config:/, one might save the path
config:/kluster1/my_app/my_key as the moniker,
so that the user could have this "linked" in ~ or added to a bookmark
tree in ~/.monkeyfm/

Though I see that monikers themself are handy enough to add as the base
abstraction, its just supporting
my "file based" mind in them, link softlinking to a parnet dir of a
moniker etc, and making it "feel" link a vfs
interface.

> 
>   
>         If you read bonobo/idl/bonobo-moniker.idl you will be able to
> contrast our implementation to COMs.

Has anyone tried this with other ORBs than ORBit? I am playing with C++
mapped orbs that have
other services too and was wondering if anyone else beat me to this
playfeild.