LoganBerryStub provides easy access to local or remote LoganBerry database servers. It attempts to hide any RPC details. That is, it (1) catches RPC failures and attempts to either recover or turn them into LoganBerry errors, (2) imports RPC interfaces from multiple servers on demand, (3) uses secure RPC conversations, and (4) tries to keep LoganBerry databases open.

The interface is identical to LoganBerry.mesa. Any LoganBerry application should be able to change its imports statement to:

The server portion of the database name is taken to be the instance under which the remote LoganBerry server has exported its LoganBerry interface. For example,

LoganQuery allows more complicated queries to be performed on a LoganBerry database than the simple retrievals provided by the LoganBerry interface. Database queries of various classes can be registered; retrieval operations are class-specific. For instance, the $Filter class returns database entries that match a particular pattern, while the $Merger class merges the entries returned by two independent queries. Filters can be cascaded to perform multiple-attribute queries (see LoganBerryBrowser.FilteredQuery). The predefined $Simple class permits operations identical to those provided by LoganBerry. Clients are free to create their own class of queries.

Two operations are generic to all query classes. These operations are syntactically identical and semantically similar to those provided by LoganBerry, except that they operate on "complex cursors" instead of LoganBerry's simple cursors:

The creation of complex cursors is a class-specific operation. Clients are free to introduce new query classes and operations for generating cursors of those classes. LoganQuery.mesa defines the following operations to generate cursors of class $Simple, $Filter, or $Merger:

The $Filter class uses pattern-matching filters that compare the value of some LoganBerry attribute against a pattern. For convenience, LoganQuery.mesa defines the following types of filters:

Several commands are available for invoking operations on a LoganBerry database from a CommandTool. These commands are registered by the LoganBerryTools.load file.

All of the LoganBerry CommandTool commands have a similar syntax, "<cmdname> <dbname> <attributes>", a command name followed by a database name followed by zero or more attribute-pattern specifications. The database name may be for a remote database, see "Convention for naming remote databases", or may be the special name "#", which is a shorthand notation for the last database name given.

An attribute-pattern specification is of the form: "<attribute-type>(<pattern>): <attribute-value>". The attribute value may be either a token or a rope literal. The currently supported types of patterns include "exact", "prefix", "wildcard", "re", and "soundex" (see LoganQuery for a description of these patterns). The pattern, along with its surrounding parenthesis, is optional. A missing pattern defaults to "exact".

A tool exists for interactively browsing and updating LoganBerry databases. Think of the browser as a convenient way of performing LoganBerry commands. To run the browser, type:

The convention for naming databases is the same as that used by LoganBerryStub (see above); both local and remote databases may be browsed concurrently. The browser reads the database schema to discover what indices exist for the database. It then builds an input form in which values for the various attribute keys can be entered. These values are treated as patterns against which database entries are compared.

For example, LoganBerryTools.df contains SampleDB.df, the schema for a sample database storing names and phone numbers. Typing "LoganBerryBrowser SampleDB.df" produces a viewer that looks something like the following:

The browser has several areas or subviewers. At the very top is the caption indicating the name of the database being browsed. Right below this is a menu with one or two lines (the display of the second line is controlled by the "AdminOps" button). The function of each menu button is explained in the next section.

Below the menu is the input form. Each line of the input form allows the user to type in a pattern for a given attribute. For instance, the browser tool shown above has an input form with two attributes: "Name" and "Phone". There may be some painting problems remaining in the browser. If what you type is not being displayed, make the browser iconic and then reopen it and the problem should go away (hopefully).

Preceding each attribute name on the input form is a choice button that allows the user to select what pattern matching is too be applied to the attribute value. Clicking on this choice button cycles through the following options:

The last line of the input form is a text viewer with the label "other attributes:". This is used to type in values for attributes that are not keys of the database. The input syntax is identical to the attribute-pattern specifications that may be typed into a CommandTool (see above).

Below the input form is another choice button that allows users to select on which attribute the output should be ordered. (To speed up queries it is best to order the output on some attribute that has a well-specified pattern.) The pattern-selection and order-by choice buttons comprise the details subviewer.

The history window optionally resides below the input form and details subviewer (it is not shown in the browser above). Whether or not it is currently displayed is governed by the "History" menu button. This area contains a list of the operations that have been executed in the past; these operations are given in a format that could be typed into a CommandTool to get identical results (except the database name is omitted). Clicking on one of these "history commands" fills in the input form with the values that previously existed and also sets the previous details. Thus, a query can be re-executed by selecting a line in the history window and clicking "Browse" again. The user is also free to change any of the values once they are refreshed.

At the bottom of the browser tool is the output area where the results of queries are displayed. This area is scrollable.

The LoganBerry Browser Tool displays the following menu buttons:

The second menu line offers the following buttons (intended mostly for advanced users):

LoganBerryBrowser.mesa provides a programmer's interface to some of the useful utilities used by the Browser and the CommandTool commands, such as FilteredQuery; see the interface for details. It also allows one to create a LoganBerry Browser that will call a client-given procedure for handling entries retrieved by the browser.