The Smithware I*net Data Server is a revolutionary way to connect users to information stored in Btrieve files regardless of whether they are using an intranet or the Internet (thus, I*net). The IDS is a multi-threaded server using NT Domain security which provides for data compression and virtual sites. The technology employed by the IDS eliminates many of the preconditions for end-user connectivity, allowing the developer to choose his development environment as well as the type of product to enable across TCP/IP.

The current state of database connectivity lies in two camps. A developer can either choose wide-area connectivity and write a web application, or he can choose network connectivity and write for the local network. In any case, a developer who wants full database connectivity in all situations is forced to make difficult choices: one can either write for the web exclusively, or one can maintain two separate sets of source code in (very likely) two different programming environments.

The first choice, developing new applications exclusively for the web, is initially appealing to many IS departments. It is not until the effort is made to create the actual sites that the difficulties arise. First, there is the learning curve of the new development environment, which is followed closely by discovery of the limitations of that environment. Then, there is the inevitable workaround of built-in HTML limitations (maintaining state information, for example). Finally, the application is ready to be deployed and the first user logs on. All of a sudden, the same application the user has been running successfully in a browser-less mode is several times slower because of the resources allocated to the browser and the virtual machine running inside of it. This is nothing that upgrading every machine in the office won't fix - until the next browser release.

This is not to say that the web does not have useful application. There are times when the advantages of a web-based application outweigh the disadvantages, such as when end-user browsing is essential (e.g., on-line catalogs) or platform independence is a high priority. However, an optimal solution would provide the ability to not only write web applications when needed, but also to develop an I*net application using the same development and end-user skills that already exist in the organization.

The IDS can provide Btrieve access in both of these situations. By combining three complimentary clients, the IDS provides I*net connectivity to the web as well as virtually every 32-bit Windows development environment available. The ActiveX is the tool of choice for applications developed with Rapid Application Development (RAD) tools, such as Visual Basic, Delphi, C++ Builder, and Visual C++. For legacy applications, the DLL client can provide a relatively painless upgrade path to full I*net connectivity. Finally, for web applications, platform independent applications, or Java gurus, there is a Java class library that provides IDS client services.

The IDS itself runs on a Windows NT Server and processes Btrieve requests made by each of these clients. It can handle requests from all types of clients simultaneously, and compresses data using the algorithm used by each client request, so compression can be turned on and off on a per-request basis. The server acts as a proxy between Btrieve and the IDS clients, passing information as depicted in Figure 1.

FIGURE 1: IDS as proxy server.

The IDS adds services in addition to straight-through Btrieve services, however. It is optimized to use bandwidth efficiently, as demonstrated with optional data compression. Likewise, DDF handling can be performed in only two calls: one to read the list of tables and one to read all the field information for a given table (these calls are processed internally in the ActiveX client). Furthermore, the send and receive buffers are not necessarily the same length. This architecture optimizes calls across the I*net that have significantly different amounts of information in the send buffer and the receive buffer. For example, a GetDirect operation only needs to send four bytes of information yet may need to receive a two-kilobyte record. The IDS allows the client to send a data buffer of only four bytes while retrieving the full record. Another advantage of the IDS that makes it ideal for an intranet is its easy configuration. While other Btrieve clients depend on a particular constellation of Btrieve settings (and as a result may even be incompatible with other, equally needed, Btrieve clients), the IDS clients do not need Btrieve settings at all. In fact, Btrieve does not need to be installed on a computer accessing Btrieve data via the IDS. This has the potential for dramatically reducing the number of support calls, and making for much simpler installation programs.

The IDS can be used to provide access to an unsecured site or to any number of virtual sites. Virtual sites are implemented whenever security is enabled; a basic, secured installation would have only one virtual site (called database sets in the server), but a more complex installation could maintain any number of sites. Each site has its own set of permissions which use NT Domain users and groups to validate logon access, and each site can provide one of three levels of access: full access, read-only access, and write-only access. Finally, each access level in each site can have its own virtual root directory - all Btrieve calls are processed relative to this root, and none are allowed to traverse back up the directory tree (although any may go down the tree - See figure 2). These virtual roots may actually exist on other machines on the local network, if desired. Because users and groups are established at the Domain level, maintaining IDS security is only a small add-on to normal NT Domain maintenance.

FIGURE 2: Examples of different configurations for IDS database sets.

Site #	Virtual Root	Example Permissions	Possible Scenario/Description
1	C:\MyData\Site1	IDS Full Access: NT Domain Users (All users have full access to the files in c:\MyData\Site1)	This would be the simplest secured setup. Each user would have to offer a valid username and password, but would have access to all of the data files allowed by the particular application. Different security levels for different tasks could be implemented via owner names and application-driven protection.
2	C:\MyData\Site2	IDS Full Access: NT Power Users IDS Read-Only Access: NT Domain Users NT Power Users would have access to files on C:\MyData\Site2\*.* and below NT Domain Users would have access to files on C:\MyData\Site2\ReadOnly\ *.* and below	This would be a situation where inquiries into the accounting system were fairly common for most employees, but only a limited subset would need entry rights or rights to payroll information. Again, security distinctions between the files in the Full-Access group could be made at the application level and/or by owner name.
3	NetWare Server\Site3	IDS Full Access: NT Domain Users IDS Write-Only: NT Guests (or web clients) NT Domain Users would have access to files on NetWareServer\Site3\*.* and below Web clients would have write-only access to files on NetWareServer\Site3\ WriteOnly\*.* and below	This setup would be appropriate if the company maintained internal security via owner names or application protection, but wanted customers and vendors to be able to add or edit their own (address) information without the possibility of their looking up someone else's data.

How To Use the IDS

As described before, the current state of connectivity options requires a decision based on pain avoidance. Which hurts least: renouncing Internet connectivity or learning a new language which is often less productive than the one currently in use? Which is less problematic: multiple source code for the same app, poor in-house performance, or constant hardware upgrades/installation/configuration? The choices that should be made first are often relegated to the status of afterthought: What do I want this program to do? What development tools do I want to use? How fast can I make this application go? Should this project come in two weeks or three weeks ahead of schedule?

Because of its ability to communicate simultaneously with multiple client types, the IDS allows the developer to choose the development environment; with this freedom comes ease of programming and the ability to experiment with new and more powerful designs. For instance, an application that would take six months to port to the web and would be accompanied by groaning and gnashing of teeth (those of the developer and the end-user) can run much more efficiently and be developed in much less time as a Delphi, VB, or C++ application. The application runs over TCP/IP, and the connection is almost completely transparent to the end-user ("almost" because an off-site user will have to click the "OK" button when the dial-up networking box appears and may have to enter an ISP username and password). The same application can run over an intranet or the Internet with absolutely no recompilation.

The first questions that should be answered before developing an I*net solution are two-fold:
1) What should this program do?
2) Who will use this application?

If the answer to the first has nothing to do with database access (a.k.a. "real work"), then the IDS will not be the tool of choice, and the project should probably be done in FrontPage or another site-building tool. If the answer to the first has something to do with Btrieve, then the IDS is likely the best solution for the job. If the program needs to provide casual access to a database, and the intended users of the application is the uninvested public at large, then the Java class library is probably the client of choice. The term "uninvested public at large" is used to describe potential one-time browsers who have made no commitment to a given site or area of interest. For instance, a company wanting to publish an on-line catalog of gardening utensils and allow ordering of the same would be better off using the Java client. The benefits of version control, platform independence, and small footprint in this case outweigh the drawbacks of a (possibly) new language learning curve and slower performance. Everyone with a web browser can run the application and purchase the product.

For another product, for instance, an online sports statistical service, the Java client may not be the best method. Since people will likely either subscribe to such a service or return to it frequently, they will likely not mind downloading and installing a 500K program, if it provides the information they seek more efficiently than would a series of web pages. For instance, the same statistics could be cached in the application memory and viewed differently without retrieving the entire mass of statistics again (as would be necessary with most web solutions). Threading can be determined by the application, and processing power could be spent on complex analysis/algorithms rather than on sandboxing a virtual 8088. Any situation in which customers need information (such as billing records or tracking information) on services obtained would also fall into this category.

If the program is to provide serious database access, or the expected end-user is someone other than Joe Q. Public, an I*net enabled browser-less application is probably the best and most efficient method for completing the project. A case study is an effective way to view how this scenario might use the IDS effectively.