This document describes web applications for which I believe the PIA is well-suited. Emphasis is placed on applications which are part of a website, rather than the whole thing; at the moment the PIA's performance is insufficient for use in high-traffic websites, and in any case we believe that webmasters are more likely to be interested in adding functionality to existing sites than in rebuilding a site from scratch.
This section makes no distinction between internet and intranet applications (both are websites), but it is expected that the PIA in its present implementation will primarily be useful in intranets. Its use in low-volume internet sites will be limited by the fact that most of these are hosted, and few hosting services or ISP's provide Java. The aggregate of these online applications would essentially be an ``intranet-in-a-box'' for a small business.
Note that the easiest way to add a PIA-based application to an existing website is to use a Servlet. This results in the PIA being ``mounted'' as a subdirectory in the website's URL space. A stand-alone PIA server could be used to provide an integrated ``intranet-in-a-box.''
Many sites, e.g. Slashdot, Linux Today, and Advogato consist almost entirely of reader contributions. In some cases the discussions may be mirrored from newsgroups or mailing lists, using software like hypermail, but increasingly these are stand-alone web applications. A discussion forum can be particularly useful in an intranet, where it can serve as a combination bulletin board, suggestion box, and help desk.
Discussion forum sites generally also have user accounts, usually enabling
other features. For example, Linux
Today shows a registered user which articles are new since their last
visit; Advogato includes a rating
system and includes user's diaries, and a list of projects. (It's worth
noting that Advogato is written in
C as an Apache module (mod_virgule), and uses the Gnome XML
library to store documents as XML.)
Here I'm thinking of collaborative environments like the Wiki-Wiki and FAQ-O-Matic servers, where an entire collection of web pages is constructed collaboratively. In an intranet, this can be particularly useful as a way of capturing group knowledge.
The classic example here is Yahoo; perhaps a better one is dmoz, which is collaboratively edited. An internal directory of this sort would be a useful addition to any company's intranet.
Portals (both configurable sites like my.netscape.com and news portals like svlug.org) need to pull in information from several different sources and present it on a single page, and so require HTML processing, information extraction, and reformatting.
As we have seen with the IM3 (eCabinet outside of RSV), a calendar-like display can be useful for many things, not just keeping track of appointments. In particular, it could be used for organizing any chronological sequence of documents or events, including mail messages, forms, firewall logs, sales figures, and so on.
Any organization should have an internal home page for every computer-using employee. These pages should, for example, present directory information, schedule, and so on in a standardized format.
We have usually just called this application category ``workflow,'' since it is concerned with the flow of forms among the various people who have to sign and otherwise handle them. It's an obvious application for the PIA, especially in a small office where the expected volume is small.
Something else that deserves to be called ``workflow'' involves the flow of, not forms, but documents. Document workflow applications are often found in print shops, publishing houses, technical writing departments, libraries, advertising agencies, and indeed web application development consultancies. The distinguishing factor in these applications is that the work product is a document or a collection of documents. The application and its forms exist simply to manage the flow of documents between clients, authors, artists, editors, proofreaders, typesetters, FTP sites, and the like.
This kind of application can be enormously useful to a small business, which may have to handle a document workflow only occasionally (e.g. in order to produce a catalog a few times a year).
A web-based document management system would include:
One of the simpler (and hence most compelling) uses of the PIA is for applying a uniform look and feel to web pages, using definitions for tags like <body>, <header> and <footer>. This can actually be used online, too, but will have to wait for CPIA before it can easily rival Apache's server-side includes.
Simple macro expansion is characterized by the use of <define> (for both tags and entities) and <include>, but little if any use of control structure. Since it requires only simple replacement, it's particularly easy for page authors to learn.
More advanced formatting operations are exemplified by the slide and table-of-contents tagsets. Here the PIA starts to approach, and in some cases exceed, the complexity and capabilities seen in, for example, LaTeX and XSLT.
It can be expected that most advanced tagsets will be built by programmers or advanced web designers (the latter probably using interactive ``wizard-like'' (``web-wizard''?) tools when they become available).
In client-side applications, the PIA works seamlessly alongside a browser that serves as its user interface, typically on the same CPU but always under the control of an individual user.
It is possible, using the PIA, to make an entire directory tree ``look like'' a single website: easy to navigate, with a uniform look-and-feel and a complete set of searchable indices. The PIA Tree Browser is a first step in this direction.
Tagsets like slides and tsdoc make it clear that
the PIA is good for reformatting HTML and XML files; it's less obvious
that it can be used for viewing files in other formats, but in fact all it
takes is a suitable parser.
The PIA can be used to construct customized sidebars, framesets, link pages, and so on for use with browsers.
The original PIA application, of course, was as a personal web proxy. The History and ad-buster agents are still useful. Caching, password management, and so on are still possible but harder.
If everyone in an organization has a personal server, it becomes possible to distribute many of the traditional functions of an intranet. For example, personal home pages and document collections might be managed and served from peoples' desktops. This structure could cut down on unrestricted sharing (i.e. via SMB and NFS), leading to an increase in security. Automatic mirroring and version control would take care of backups.
This structure for an intranet takes advantage of the fact that disk space and compute power are commodities now. In a way it's the inverse of the ``traditional'' file-server-centric structure: everyone's personal machine becomes their own storage device, while the centralized server provides only document-management services such as indexing, search, version control, caching, and backup.
Inverse proxying provides an good way of doing security: all requests for other people's documents go through a centralized server, which in turn proxies the request to the appropriate personal server using the authentication information of the requestor. This makes it unnecessary for everyone to authenticate separately with everyone else's personal server.
Although the PIA can construct non-XML files, it's more interesting to consider its uses for constructing and editing configuration files for XML-based applications such as Mozilla (not to mention the next version of Apache and the PIA itself). XML data files (as opposed to documents) tend to be unmanageably complex and rigidly-structured. ``Wizard-like'' web-based tools for constructing them would be welcome, and the PIA provides an easy means of building such tools.
This covers a fairly wide range of wizard-like or template-like
applications for generating such things as tagsets, DTD's, XML Schemata,
web pages, and even whole web applications. See web-wizards.html.
One thing that networked appliances always need is a web server for managing their configuration. This includes web server configuration, file server configuration, configuration for specialized hardware, and so on.