Re: more moniker questions

[Michael Meeks <michael helixcode com>]

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.
  
        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.
  
        Regards,
  
                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot