Possible Search Systems

One possible method for getting the necessary information out to the users would be to create a booklet listing the available families and the member parts. There are several publications in existence listing standard Raytheon parts, but these are just the specifications for the physical parts, and do not contain any information about CAD parts.

There are several problems with this solution. First, there are many designers, spread throughout several plants. Getting this information to all of them would consume much time, and a lot of paper. The designers also work in different technical areas, so each would probably only use a small fraction of the available parts. Second, this also is a dynamic set of families and parts. Each time a new family or part is added, updates would have to be sent out to all of the designers. Third, the designers can not afford to spend a lot of time searching through a printed book to find the parts they need. It would be less time consuming in most cases to just rebuild the parts. Finally, the company has spent a great deal of time and effort computerizing much of their documentation. They have connected all of their designers through computer networking. The optimal solution would be to use this network to provide the information. Since any changes can be made available to all designers immediately, and, if properly designed, the search would take little of the designer's time, this is the most cost effective and efficient solution.

Once that decision was made, there were still several possible options. An early suggestion was to create a database of part information using a commercially-available database program. Unfortunately, the only databases available were PC based, and there are very few PCs available to the designers. If they have to spend their time hunting around for a free PC instead of being able to perform the search from their workstation, then that wastes valuable time, and again would reduce the amount of use of the system. Another possibility was to just make the part tables available for people to search through. These files can be very difficult to read, especially if there are many variables causing entries to wrap over several lines. Also, some families get vary large, such as the 795 member handle family. Reading through a file that size to find one specific part would be very time-consuming.

The first workable option was to create a search engine similar to the ones already in use by the designers. Also, the use of World Wide Web servers and browsers to distribute information throughout the company is becoming more and more widespread. Because of this, a Common Gateway Interface (CGI) based solution was another usable option.

The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information. [CGI]

In the end, both of these options were used, creating both a familiar text-based search engine, and another one that uses a CGI script, written in Perl, to create HyperText Markup Language (HTML) forms for the user to fill out and submit. HTML is the markup language used to write the majority of web pages.

The search engines were written in Perl, which has some excellent functions for performing searches. It also has the additional benefit that the program is compiled when it is started, making maintenance of the program easier. Programs of this type written in Perl are also generally faster than similar programs written in C.

Last Modified: Wed Aug 28 14:41:29 EDT 1996