What you see here is the HTML-version:
1. Introduction
1.1 The Problem:
People who work a lot on Telnet/SSH shell accounts are often faced with considerable difficulties if they attempt to do edit text files on their accounts.
The machines they are working on may be located on remote sites and are connected to the user through the internet. This may result in bad terminal response times if either side has a slow network connection - either because it doesn't have much potential in the first place (think 56k and less modems), or because most of the bandwidth is already occupied by other services. Slow terminal responses obviously hinder text editing because the user cannot immediately spot spelling mistakes anymore. The user either has to type very slowly, always keeping up with the speed at which characters are echoed back on the screen, or he has to ignore the possbility of typos, type as usual, and go back to correct mistakes later. Depending on the speed of the connection, going back may be another considerable waste of time. It is also psychologically very annoying having to wait a long time for the typed text to appear on the screen.
Another problem is terminal incompatibilities. We are still stuck with the archaic termcap/terminfo terminal databases and terminal descriptions that differ widely between the various Unix systems. If you are lucky, ansi and vt100-compatible terminal descriptions will generally make a screen editor like ``vi'' usable, but if you wish to use ``advanced'' features such as the page up/down, pos 1 or end-of-line keys, you will need a more complete description of the exact terminal type you are using - be it software-emulated or real. One help is the ability to specify your own termcap database e.g. by using the TERMPATH environment variable if your implementation supports it. That way, you can copy a termcap description entry from your native system to the remote site so that termcap-based applications can use it instead of the system-wide database. The drawback of this approach is that it does not apply to terminfo (you may be able to decompile and recompile terminfo bianry files for different systems, but don't count on that)
And finally, the system you are working on may not have your favorite text editor installed. This one is not directly an argument for using nwpedit because the nwpedit server must be loaded on the target machine as well before it can be used, but at least nwpedit is likely much smaller than your favorite text editor :-)
1.2 The Solution:
If you have decided that editing a file on your account via Telnet or SSH results in more trouble than it's worth, there are already many ways existent ways to work around the limitations. You could, for example, download files via ftp or ssh (scp.) Doing so would of course also result in delays if your problem is connection slowness, but it would certainly be less annoying than editing the files directly.
The drawbacks of these solutions:
- Downloading, editing and uploading manually any time you want to
change something is a daunting task
- With these tools you are always transferring complete files. If
you only change five bytes of a 50kb file, you will still upload
50kb
nwpedit consists of a client and a server application to automate the work of downloading those files, loading them into your favorite editor, and sending back your changes, if any. nwpedit can transfer either complete files or patches, it supports IPv4 and 6, has a cache for directory listings and files that can be used in write-through (always commit changes) or write-back mode (only commit changes when asked to), and it is not tied to any particular text editor application (you can have it launch any program you want.)
1.3 Status of nwpedit:
The current version of nwpedit was developed within roughly one week of my vacation. It still lacks many features and certainly cannot be considered to be complete by any definition. For example, the directory listing cache is not used yet, the distinction between write-through and write-back is not made yet, and the option to check the cache for consistency on every file access is not implemented yet. Generally, there aren't many configurable options either. Worst of all, there is only a provisionary plaintext password authentication. And the server isn't even a daemon!
So why this release? Because I wanted to get the program ``out the door'' as soon as possible and because it actually works. I have ``started'' developing nwpedit in July 2003. The first version was so bad and full of ugly kludges that I was never motivated to finish it. Then, about a month ago, I finally deleted all the old stuff. And now I have rewritten it within a week and it is already so much better and more functional.
By releasing this stuff now, I can finally prove that nwpedit is no vaporware.
nwpedit is known to work on FreeBSD 4.x, SuSE Linux 8.2, HP-UX 11i, Tru64 UNIX 5.1B and IRIX 6.5.??. Client and server will soon be tested on AIX and Solaris as well. The client may be ported to Windows NT and derivatives in the near future.
No nwpedit development is happening anymore. I rarely use it, but when I do, it works for me.
|
|