Autor: Jude Nelson Data: A: Hendrik Boom CC: dng@lists.dyne.org Assumpte: Re: [Dng] OT: separate GUI from commands (was: Re: The more things
change, the more they remain the same
Hi Hendrik,
On Wed, May 27, 2015 at 12:35 PM, Hendrik Boom <hendrik@???>
wrote:
> On Wed, May 27, 2015 at 02:27:17PM -0400, Jude Nelson wrote:
> > Hi Hendrik,
> >
> ... (much snipped) (I'm sorry, I hadn't meant to take you away from
> vdev for the amount of time it took to write this lengthy and
> interesting reply)
>
> >
> > An interesting consequence of structuring applications this way is that
> you
> > can trivially solve both network transparency and application
> distribution:
> > simply put the application on an NFS mount (or some network filesystem),
> > and run the interpreter on the local client. The application stores
> > runtime state as files within its directory hierarchy, so they get
> > automatically written to the NFS server. Users could run remote
> > applications locally simply by mounting the remote volume and running the
> > interpreter on them in-place.
>
> >
> > I was considering building such an interpreter as well as and a suite of
> > applications for Devuan at some point, after finishing vdev. I was
> > thinking of calling it "shui"--both from the concept of "feng shui" (the
> > idea of harmonizing everyone with their environment), as well as serving
> as
> > an acronym for "SHell-oriented User Interface".
>
> Sounds interesting. But for applications like ordinary text editing,
> it might become a little slow if you end up running a shell script
> with every character typed. The idea did seem to work somewhat for
> the ancient mail handler MH (if I recall correctly).
>
> But as for the file system ... I wonder if the completely virtual file
> system in something like Inferno could help things along -- put more
> of the primitive operations into the file itself. Or have I
> misunderstood Inferno?
>
> Of course, taking this to its logical conclusion would move the
> file system rather seriously in the direction of a typed persistent
> objects system, with methods and so forth. A very different beast
> from what we're used to.
>
These are excellent points. I should clarify, shui itself would be
designed as an aggregate of programmable widgets. Each one would know how
to render itself, and how to interpret a particular directory and run its
scripts. One such widget would be a text area with the capabilities you
originally described. The value shui provides is that it would make it
very easy for users to swap out parts of the text editor they didn't want,
or mix and match components without having to become developers and without
having to re-compile the application.
I don't think we'd need a typed persistent object system at the end of the
day, since unless all application developers agreed to it, there wouldn't
be a unified type system in the first place. Flat files of bytes should be
just fine for the purpose of developing applications--if the application
needs an advanced type system, it can implement it itself.