Re: more moniker questions

[Dietmar Maurer <dietmar maurer-it com>]

Michael Meeks wrote:

> Hi Dietmar,
>
> On Wed, 29 Nov 2000, Dietmar Maurer wrote:
> > >         This capability should be split out, and a sane way of
> extending
> > > pre-written monikers implemented. Either way, if you are writing an
> efs
> > > moniker, please use the:
> >
> > Ok, I see it ;-) The file/ftp/http/... moniker is able to return a
> > BonoboStream - nothing more. And we have a general
> > way to extend the functionality of a moniker, more or less
> > something like:
> >
> > transform_object (object, requested_interface);
> >
> > which does exactly what is now contained in the file moniker
> > and duplicated in the http moniker. We can also extend it to
> > query for an object which transforms a Stream into a
> > Storage (tar, efs, zip, ...)
>
>         Yes; I would like a system like this; you see, otherwise the
> problems become legion:
>
>         If we ( as some suggest ) just start folding everything into the
> file moniker, we have hidden the power of monikers and made everything
> very ambiguous IMHO. So:
>
>         file:/tmp/a.efs  vs. Control
>
>         Has to solve all manner of evil problems, such as whether we want
> to turn it into a stream and activate something that handles
> PersistStream, whether we want to turn it into a storage and activate
> something that handles PersistStorage, whether to leave it as a file and
> activate something that handles PersistFile etc. etc. and I just don't
> want to go there, whatsoever.

I do not see this problem, because if I have a program/control that saves
its state to a storage it also associates a mime type with it - right. So the

storage file is not called file:/tmp/a.efs - it is called
file:/tmp/a.gnumeric
(it has an associated mime type). The situation is not that bad as you
described it.

>         So we should go with the explicit approach:
>
>                 file:/tmp/a.efs#efs:/
>
>         And then we need to deal with the case of "I can't resolve this
> storage vs. FooBar interface" in a flexible, extensible and clean way. I
> don't want the rush to implement monikers to lead to a bad design. I would
> prefer people spent the time fixing eg. escaping in the core, rather than
> cluttering the place up with umpteen new monikers. I would also greatly
> appreciate reducing further the number of lines of code needed to create a
> moniker, ideas there are welcome too.

One idea is to write the generic transform_object () method and use it for
the file and http/ftp/... moniker.

- Dietmar