Different output styles could be supported.

Ideally this would use the proposed OUTLINE tag described below.
Most simply, the overview would just list the page title in their hierarchy, optionally with heading contents. Obviously all items would be real links.
More cleverly, use frames, with the main frame having the main contents; clicking on a main topic would show all the subsidiary topics in another frame.

Normally just specify "entry point" page, eg index.html or default.htm, and the output page to create, as well as any options. The program would then index all "local" pages from the entry point.
Optionally parse all pages in the current directory (and sub-directories).

Remember to avoid cataloging pages that are overview pages, to avoid recursion.

It could be argued that ordinary links could be used instead of this. Alternatively, a frame pair could achieve the same effect. However, a contents list would be best shown using this proposed OUTLINE tag.

DONE

Needs a help index data file, linking index word to link point.

Data file could be generated by the Site Overview Generator.

This would be especially useful for Web API overviews.

Work out non main heading indices either from links within pages, eg #help. Alternatively pick up new tags, eg <X-INDEX>, and link as best as possible (or insert link points).

Possibly unnecessary as Netscape already keeps table rows together on a page.

Other authors may wish to link to specific line within a web page. To do this, I propose that browsers recognise <A HREF="#--lineno">, where lineno is the line number of the HTML document, starting from 1 and counting a CR, LF or CRLF as a line end, eg <A HREF="#--100">. The browser will do its best if the line number does not make sense.

The main draw back is that such links depend on the original page not changing. So perhaps just having the author's named links is better.

(B) Please put two spaces after period, colon and semi-colon characters.

(C) Have a zoom facility to enlarge detailed pictures.

Why not have an FTP agent on your local server? Simply put in a request for the required file. That night the agent brings the file over onto the local FTP server. You download it quickly the following day.

Popular files can be cached, so your file may already be there.

Do some big access providers already do this sort of caching (for web pages)?

An alternative that will work currently is to do FTP by email, if you can cope with it.

The user can fill in the form, make list box selections, etc. The results are can be

• sent to a CGI/ISAPI program using GET or POST methods
• sent by email (using an SMTP server on the applet's host)
• loaded by FTP (onto an FTP server on the applet's host)
• stored directly on disk (applications only)
• returned to the calling Java program (class-set only)

Write a companion program, a "Wizard/Expert" to let you design forms.

As well as all the basic field types, also provide classes derived from TextField which support integers, doubles (both with ranges) string, dates, email addresses, passwords, etc.

Initially using GridBagLayout, it might need a new Layout.

This will need to reuse or write SMTP and FTP client classes.