[MSH] Thoughts on Monad, Monad-enabled editors, virtual filesystems and more

Discussion in 'Scripting' started by Lionel Fourquaux, Jan 29, 2006.

  1. This post is a collection of ideas and suggestions that I'd like to share
    with the community.

    MSH intoduce an extensible filesystem-like view for many system resources.
    Currently, this includes the physical filesystems and the registry, and
    several extensions exist or were proposed (WMI namespaces, .Net classes).
    Now, it seems to me that we can expect providers for remote filesystem
    access in the near future. (Someone will probably soon take the time to plug
    putty of openssh into a Monad provider, to get SFTP access in MSH, and it
    would probably be reasonably easy to add webdav access). A filesystem-like
    view for things like IMAP or MAPI mailboxes and the window's tree could also
    have interesting applications (e.g. take the text content of _this_ window,
    push it through a complex pipeline, and put the result into _that_ one -
    easy mix between command-line and GUI tools).

    Remote filesystem access give you the possibility to process files on remote
    computers from Monad, using the resources of the local computer. This is
    great, as long as you stay within the Monad model. However, you can't step
    outside it. For most purposes, this is no great problem (just copy the
    files). However, it appears to me that having some sort of Edit-Item cmdlet
    would be _very_ useful. This would give you, nearly for free:
    * a file editor (of course)
    * a registry editor
    * (with an hypothetic provider) an editor for remote files
    * (with a provider for windows on the current desktop) a plugable editor
    for _any_ application
    * an advanced pager (just pipe the data into the editor)
    * possibly, a command-line/history editor.

    Of course, there is also some good reasons _not_ to provide an Edit-Item
    cmdlet with MSH: people may prefer different editors (vi vs emacs,
    someone?), and MSH extensibility sould make it possible to reuse existing
    editors (it may not be easy, though, since they were not designed from the
    start for such a use; moreover, a Monad-enabled editor may be designed to
    modify objects rather than only text). Nonetheless, it may be an interesting
    idea to provide a rudimentary standard editor by default.

    This is part of a more general pattern: applications will get more power
    from Monad if they provide cmdlets rather that external commands, and
    COM/.Net objects models rather than monolithic GUIs. In a way, this is yet
    another development in the direction of a fully object-oriented environment,
    with the line between applications and libraries being increasingly blurred.
    (Maybe someday it'll disappear, but this is stuff for research OSes).

    Another interesting (IMHO) thing is that we now have three major
    filesystem-like spaces for userland Windows: the Win32 one (built on top of
    the object manager tree), the Shell namespace (built on top of Win32), and
    Monad providers (on top of .Net and Win32). Some unification may be
    beneficial, but difficult due to compatibility constraints.
    Lionel Fourquaux, Jan 29, 2006
    1. Advertisements

  2. Lionel Fourquaux

    Nick Guest

    I actually really would like to develop an explorer-like program that uses
    MSH as it's data provider, and uses snapins (or some similar system) to allow
    arbitrary editors (as controls, perhaps).

    Maybe...with WPF's composition model...hmm...

    Anyways, your questions are exactly what I've been thinking about. I would
    also really love to see a new implementation for the standard dialog commands
    (save, open, etc.) that uses MSH.

    Nick, Jan 29, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.