Date: Wed, 1 Oct 1997 22:37:48 +0200 From: Peter Korsten <peter@grendel.IAEhv.nl> To: chat@FreeBSD.ORG Subject: Browser interface (I changed the subject) Message-ID: <19971001223748.33773@grendel.IAEhv.nl> In-Reply-To: <11391.875672994@time.cdrom.com>; from Jordan K. Hubbard on Tue, Sep 30, 1997 at 07:29:54PM -0700 References: <Pine.BSF.3.96.970930210221.21190K-100000@Journey2.mat.net> <11391.875672994@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard shared with us: > > We have a big engineering task: How to front-end a wide variety of > system installation and administration tasks so that the user isn't > stuck trying to figure out how to use arcane commands like disklabel, > newfs or pkg_add if they really don't want to. I think we're all in > general agreement on the size and shape of the problem space. I think the installation part is not the main issue. Under normal circumstances, you will have to install a system just once. After that, you have a system to maintain on a daily basis. Since many of us aren't getting each other's points (or better, we don't get that we're basically agreeing, but I'll explain that later on): I doubt whether the interface should be limited to the most common denominator, which in any case is the text interface. Frames, for instance, aren't really possible with just a text interface. Although frames are often scoffed at (because many site builders don't know how to use them), they are an ideal means for navigation. It's a real pain that NCSA Mosaic 3.0 (for Windows) doesn't support frames, because for the rest, it's a very nice browser. A true web-like interface also gives you the possibilty to create your own personal interface, because you can simply edit a template HTML file. Admitted, the installation procedure could use an update. But is it really essential that 'the new way' includes this one-time task as well? To give a popular example: if I install NT, I begin with a text screen and later on, I get a 640x480x16c screen. Only when I'm finished, I can switch to my multi-color high resolution display. I don't know enough of the Juliet system, but it sounds promising enough. What I really want to know is: could a front-end be written that talks to Juliet and looks like a database - more specific: an ODBC data source - from the outside? Consider the following SQL statement: SELECT * FROM myhost..users WHERE usercode LIKE 'e%' which would give you all users on machine 'myhost' in the password file, whose usercode begins with 'e'. How about installing new pieces of software? "UPDATE myhost..packages SET name = 'apache', location = 'ftp://ftp.apache.org/...'" or something? In that case, all you need for the rest is a HTTP server with an extension or CGI that can parse 'extended HTML' files. (I know that I could have picked a better example, but MS IIS with IDC is one, though it's pretty limited. But I think there are also solutions for Unix.) If someone's browser doesn't support frames or graphics, provide an alternate set of extended HTML pages. That is far less complicated than writing different applications for text and graphical interfaces. As I come to think of it, this also makes it possible to use this scheme for the installation process. I don't think that a homebrew GUI is a solution. It's a lot of work and you won't be able to easily transport it to other systems. As mentioned, I don't want a text interface either (I presume that's what Jordan meant with a CUI). The third option is the browser. I really believe the browser to be the user interface of the future - well, for the next five to ten years at least. It's platform-independant and it can be made very beautiful. If the database look-a-like option could be implemented, three of the four needed parts are already there or almost there: the browser, the web server with the extension, and Juliet. OK, what did I forget in this magnificent plan? :) - Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971001223748.33773>