Design features

TurboLog 4 capitalizes on the the profound skills of professional software developers who are familiar with the leading edge of software technologies. Consequently TurboLog 4 is based on an object oriented (OO) software design using state of the art design tools including an integrated software development environment. An object denotes an aggregation of software routines which are offsprings of a set of modules that share properties in a hierarchical order. Objects of the same pedigree inherit properties of their ancestors. The practical benefit of this approach is the modular structure of the software, reusable units that all exhibit the same set of properties while they need to be designed just once and a much improved performance with respect to maintenance and future extensions. These are important benefits for the users of ham radio software.

Following the basic design options TurboLog 4 is implemented in OO-PASCAL using Borland's DELPHI development environment. This decision offers a number of options for the future of this product. Borland's updates on DELPHI will not only reflect improvements in the WINDOWS world but also include options for a future release of TurboLog 4 for LINUX by applying the KYLIX crosscompiler. For the time being, however, we will restrict our developments to WINDOWS.

Another important consideration concerns the database to be used. TurboLog 4 features NexusDB the successor of the FlashFiler database system.  NexusDB/FlashFiler is a true client/server database system. This means that all requests to view tables, create tables, add records, query data, etc. are sent from a client application (....the task which you just requested from within the program...) to a server application which actually carries out the task. The server receives the requests, performs the necessary actions, and then sends the results, if any, back to the client. Often, there are many clients sending requests to the server very rapidly. Since the server is the only application that actually manipulates data, it acts as the central manager for all table operations and ensures that the many requests are completed without compromising the integrity of the data.

For comparison, database systems such as Paradox (BDE) and Microsoft Access are file-sharing systems. This type of database system accesses the tables directly. One problem with this type of system is that each client maintains its own copy of the data. When the clients update the data file there is a possibility that more than one client will try to update the same data at the same time. This can cause the table' s data to be corrupted if some type of an anomaly, such as a power outage, occurs.

The interesting aspect of the client/server concept in the NexusDB/FlashFiler database system is the option to create a separate server application, in which the server hardware may be located at a remote site, or you can embed the server inside your client application. The first implementation would allow clubs or contest groups to operate on just one common database system from remote sites via a network. This is of great value for a number of discerning contesters and DX-peditioneers. In the latter case the user would not even realize this internal structure since it will be completely hidden from him.

We decided to start TurboLog 4 under the embedded client/server concept. If there is sufficient demand for a multi-site client/server version we will make it available at a later release.

The design and implementation of interfaces from TurboLog 4 to external devices is based on the APRO tool package by Asynchro Professional.

This topic was last edited on  Monday, 03-Jul-2023,  at  23:56