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.
