[prev in list] [next in list] [prev in thread] [next in thread]
List: gnome-components
Subject: Re: more moniker questions
From: Dietmar Maurer <dietmar () maurer-it ! com>
Date: 2000-11-29 12:58:13
[Download RAW message or body]
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
_______________________________________________
gnome-components-list mailing list
gnome-components-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-components-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic