Object-oriented communications framework system with support for multiple remote machine types

Abstract

A system enabling an application programmer to construct a plurality of application programs for communicating with a plurality of remote machines of a plurality of machine types, each of the plurality of remote machines having remotely accessible data and remotely performable operations includes a computer system with a memory, a processor, and a mass storage device, the computer system for storing programs, class declarations, and class libraries in an object-oriented programming language, means for compiling files containing source-code representations of application programs in the object-oriented programming language, implementations of a hierarchy of data description classes, each implementation for describing a set of data and for describing methods for manipulating the set of data, implementations of a hierarchy of remote data description classes, each implementation for describing data items contained in one of the plurality of remote machines and for describing methods for accessing the data items, and source code files for a plurality of sample application programs, each sample application program for communicating with at least one of the plurality of remote machines.

Claims

What is claimed:

1. A system enabling an application programmer to construct a plurality of application programs for communicating with a plurality of remote machines of a plurality of machine types, each of the remote machines having remotely accessible data and remotely performable operations, the system comprising:

a computer system with a memory, a processor, and a mass storage device, the computer system for storing programs, class declarations, and class libraries in an object-oriented programming language;

a compiler for compiling files containing source-code representations of application programs in the object-oriented programming language;

implementations of a hierarchy of data description classes, each implementation for describing a set of data and for describing methods for manipulating the set of data;

implementations of a hierarchy of remote data description classes, each implementation for describing data items contained in one of the plurality of remote machines and for describing methods for accessing the data items; and

source code files for a plurality of sample application programs, each sample application program for communicating with at least one of the plurality of remote machines, the source code files including source code to be edited by the application programmer.

2. The system of claim 1, wherein the data description classes further includes data types, data sizes, and permissible values for the set of data.

3. The system of claim 1, wherein the remote data description classes further includes data types, data sizes, permissible values and location information for the data items.

4. The system of claim 1 further comprising implementations of application state classes, each implementation for describing application items for the plurality of remote machines.

5. The system of claim 4, wherein the application items includes pointers to the implementations of the hierarchy of remote data description classes.

6. The system of claim 4 further comprising implementations of a graphical user interface class, each implementation for maintaining a link to the implementations of the application state classes.

7. The system of claim 1 further comprising implementations of operation request queue classes, each implementation for storing requests for operations to be performed on the plurality of remote machines.

8. The system of claim 1 further comprising implementations of operation request queue classes, each implementation for storing requests for items of data to be transferred to the plurality of remote machines.

9. The system of claim 1 further comprising implementations of a parser class, each implementation for retrieving during runtime a representation of a plurality of object instances contained in a data file and for enabling the application programs to create in the memory a plurality of object instances from the representation of the plurality of object instances.

10. The system of claim 9, wherein the representation of the plurality of object instances includes a textual representation of the object instances to be created in the memory.

11. The system of claim 10, wherein the textual representation of the of the object instances to be created includes names of classes of the objects to be created and textual representations of the values of their instance variables.

12. The system of claim 1 further comprising implementations of a base class in a data file, each implementation for describing methods for creating representations of object instances of a subclass of the base class.

13. The system of claim 12 wherein the data file includes textual data.

14. The system of claim 1, wherein at least one of the sample application programs is adapted to run on a computer system which is external to the at least one remote machine being communicated with.

15. The system of claim 1, wherein the remote machines include office machines.

16. The system of claim 1, wherein the remote machines include off-site office machines.

17. A computer program product, for computer systems each including a processor and a memory, the computer program product for enabling an application programmer to construct a plurality of application programs for communicating with a plurality of remote machines of a plurality of remote machine types, each of the remote machines having remotely accessible data and remotely performable operations, the computer program product comprising:

a computer readable storage medium comprising:

code implementing a hierarchy of data description classes, which code is configured to describe a set of data and to direct the processor to manipulate the set of data;

code implementing a hierarchy of remote data description classes, which code is configured to describe data items contained in the plurality of remote machines and to direct the processor to access the data items; and

source code files for a plurality of sample application programs, the source code files being configured to reveal source code for text-editing by the application programmer using a computer, the source code for each sample application program configured to, after compilation, direct the processor to communicate with at least one of the plurality of remote machines, the at least one remote machine being external to a run-time computer system on which the application program is running.

18. The computer program product of claim 17, wherein the remote machines include office machines.

19. The computer program product of claim 17, further comprising a processor and a memory.

Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates generally to the area of service tools for remote machines. More specifically, the present invention relates to communication between service application programs in computer systems, and remote devices such as remote machines and external data in files, databases, and programs.

Object Oriented Programming

An understanding of object oriented programming and object-oriented application frameworks will assist in full understanding of the present invention. As is understood to one skilled in the art, an "object" is an abstraction of a real world entity and is implemented as a combination of a data structure (whose fields are called "attributes" or "data members") and a set of operations ("methods" or "member functions") that can be performed on it. A "class" is a data type for a set of objects that each have the same data structure and the same operations. An "instance" of a class is an object, the data type of which is the class, as actually embodied in the memory of a running application program.

Classes are grouped into one or more (compile-time) hierarchies based on "inheritance," which allows the interface (i.e. the names and types of the attributes and methods) of a "subclass" to be specified in terms of its differences from those of one or more "superclasses." Instances may be grouped in one or more (run-time) hierarchies by "containment"; an object that contains a plurality of other objects is called a "container" or a "collection." Further information regarding object oriented programming concepts are found in The Annotated C++ Reference Manual by Margaret A. Ellis and Bjarne Stroustrup, Addison Wesley c 1990.

An "object-oriented application framework" consists of a library of classes that are designed to be extended and subclassed by the application programmer, packaged along with several illustrative sample applications that use those classes and which are designed to be modified by the application programmer. The sample applications generally constitute a system that is useful in its own right. In general, the basic concept of a framework is well known to one skilled in the art. Some example frameworks include X Toolkit, Motif Toolkit, Smalltalk Model-View-Controller GUI, and MacApp.

Remote Service Application

An "application" is a program or set of cooperating programs that enable a user of a computer system to accomplish some task or set of tasks.

Remote Service Applications are applications that allow a computer user to communicate with and perform services (operations) upon machines (remote machines) that are separate from the user's computer system, possibly at a remote location, i.e. off-site. Some examples of remote machines include office machines such as copy machines, facsimile machines, and phone systems; and software entities in the memory of some remote computer system such as a file server or database server, etc. The typical actions performed with remote service applications include remotely diagnosing problems of a remote machine, monitoring the usage of the remote machine, enabling/disabling features of the remote machine, retrieving data, changing parameters, etc.

The present invention also supports applications that communicate with and perform operations upon software entities such as files and processes that are contained the same computer system as the application program; we will use the term "remote machine" with the understanding that it may also include processes and files in the user's machine, but external to the memory and process controlled by the remote service application program.

To access a remote machine, the remote service application uses a "device driver" associated with some interface device such as a modem, and a "protocol driver" that formats the data sent to and received from the remote machine. These drivers may be part of the operating system or may be modules within the application program.

In the past, remote service applications were individually customized for each type of remote machine. For example, a first remote service application communicated only with machines having a particular protocol, whereas a second remote service application communicated only with machines having a different protocol. An advantage of this customized approach is that the remote service applications are efficient because they are tightly coupled to the architecture and parameters of the respective remote machine.

One disadvantage to individually customized remote service applications is that each software system often includes functions and data that are commonly used and duplicated for each system, such as customer databases. Another disadvantage is that each time a new type of remote machine is manufactured, a new software system needs to be created to address the unique capabilities of the new type of remote machine. The problem with this is that the software system is often built from scratch; thus the development cycle time is high. Yet another disadvantage is that individually customized approaches are often inflexible. Typically once a software system is on-line, modifications to the software system are very difficult because of the numerous ramifications to other parts of the software system.

What is needed is a set of software mechanisms by which a remote service application can communicate with and operate on any one of a plurality of remote machines, and a method for developing these remote service applications, that avoid the disadvantages disclosed above.

SUMMARY OF THE INVENTION

The present invention relates generally to the area of service tools for remote machines. More specifically, the present invention relates to communication between service application programs in computer systems, and remote devices such as remote machines and external data in files, databases, and programs.

According to a preferred embodiment of the present invention, a system enabling an application programmer to construct a plurality of application programs for communicating with a plurality of remote machines of a plurality of machine types, each of the plurality of remote machines having remotely accessible data and remotely performable operations, includes a computer system with a memory, a processor, and a mass storage device, the computer system for storing programs, class declarations, and class libraries in an object-oriented programming language, means for compiling files containing source-code representations of application programs in the object-oriented programming language, implementations of a hierarchy of data description classes, each implementation for describing a set of data and for describing methods for manipulating the set of data, implementations of a hierarchy of remote data description classes, each implementation for describing data items contained in one of the plurality of remote machines and for describing methods for accessing the data items, and source code files for a plurality of sample application programs, each sample application program for communicating with at least one of the plurality of remote machines.

According to another embodiment of the present invention, a method for constructing a plurality of application programs using an object-oriented programming framework in a computer system, each of the plurality of application programs for communicating with a plurality of remote machines, each of the plurality of remote machines having remotely accessible data and remotely performable operations, includes the steps of choosing a suitable sample application program from a plurality of sample application programs contained in the object-oriented programming framework, modifying the suitable sample application program to form a modified application program, and compiling the modified application program.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system 110 according to a preferred embodiment of the present invention;

FIG. 2 illustrates a block diagram of an object-oriented application framework for use in a preferred embodiment of the present invention;

FIG. 3 illustrates a block diagram of the sample remote service application programs and data files supplied with the framework for use in a preferred embodiment of the present invention;

FIG. 4 illustrates the representation, in a preferred embodiment of the present invention, of the component, graphical user interface, application state, machine model, and queue objects that describe a remote machine;

FIG. 5 illustrates the representation, in a preferred embodiment of the present invention, of a remote facsimile machine and the corresponding component, machine model, and application state objects, and their relationship to the data contained in the remote machine;

FIG. 6 illustrates the representation, in a preferred embodiment of the present invention, of the objects that are required in order to communicate with and operate upon a remote machine.

DESCRIPTION OF A PREFERRED EMBODIMENT

Overview

A preferred embodiment of the present invention is part of the REST ("Ricoh Electronic Service Tool") object-oriented application framework which is currently under development by Ricoh Corporation, the assignee. An object-oriented application framework ("framework") comprises a class library that includes the declarations and implementations of classes of objects, and a plurality of sample application programs written using those classes.

A framework is a system that enables an application programmer to quickly and easily write new application programs in some application domain, e.g. (in the case of the present invention) remote service applications. In particular, the application programmer typically edits sample application programs that have been written for a particular remote machine to create a new application program.

The object classes in the framework that are part of a preferred embodiment of the present invention, when instantiated as software objects within the memory of a computer system, constitute a mechanism and an associated method that enables any application program implemented using them to communicate with a plurality of remote machines, of a plurality of different types.

The sample applications also constitute a system in their own right, for performing some set of tasks, e.g. (in the case of the present invention) remote service tasks.

Definitions

A "component" is a software object that represents the services and state of some remote machine. A component may have sub-components, e.g. a copier may have a sorter and a feeder attached to it.

A "device" is a computer system peripheral that enables the computer system in which the remote service application is running to communicate with one or more remote machines.

A "device driver" is a software object that provides an interface by which the remote service application communicates with a device.

A "machine" is any hardware or software entity that is external to the computer system in which the remote service application is running; i.e. a remote office machine, file server, or database server.

A "machine model" is a collection object, the contents of which are "model item" objects, describing the services provided by some component.

A "model item" is an object that describes an individual service item provided by some remote machine.

A "service" is any operation that can be performed on or by a component, including retrieving or updating data contained in that component.

A "service item" is an abstract class that describes a service or set of services, or the data currently contained in a service.

A "machine state" is a collection object, the contents of which are "application item" objects.

An "application item" is an object that contains the information the remote service application has about some service provided by the remote machine, including the current state (data) of the service in the machine and any changes or operations that the end user of the program has requested and that have not been performed.

Naming Conventions

The following is a summary of the naming conventions used herein and in the attached software appendix. The names of classes are capitalized, with internal capital letters to indicate the start of words. Names of global functions, variables, and classes have a one- to three-letter prefix that indicates the general family to which they belong. For example, the data structure that describes a service item, and all of its subclasses, have a prefix of "SI.sub.--." Classes that descend from "R.sub.-- Base" have the prefix separated from the rest of the name by an underscore; "R.sub.-- Base" is the base class for objects that can be put into collections, written into external files, and read back from those files.

Classes and data types whose names lack an underscore are usually instantiated as variables, function arguments, or class data members, and are passed by value; classes whose names include an underscore are almost always instantiated on the heap and passed as references or pointers. This convention allows one skilled in the art of object-oriented programming to easily distinguish classes from instances, and instances from references or pointers to instances, in the discussion that follows.

The names of global functions, constants, and variables have a lowercase prefix.

Member functions and data members that are part of a class's public interface start with a lowercase letter. Protected data members have a name ending in underscore; there is usually a public member function to access the data; its name is the same but without the underscore. Such data members are called "attributes," and are declared using macros whose names start with "R.sub.-- ATTR."

If there is a member function that updates a value, its name ends in "Set"; the update function is declared by the same macro that declares the attribute.

1. System Overview

FIG. 1 is a block diagram of a computer system 1 according to a preferred embodiment of the present invention. Computer system 1 includes a display monitor 10, a keyboard 20, and a mouse 30, and computer 2. Computer 2 includes a processor 40, a memory (e.g. semiconductor RAM) 50, a mass storage device (e.g. a disk drive) 60, and a communication device (e.g. a modem) 70, and a system bus 80 interconnecting the above components. Mouse 30 is but one example of a graphical input or pointing device. A remote machine 90 is typically coupled to system 1 via a communication device such as modem 70.

In a preferred embodiment, system 1 is a 80486 microprocessor class based machine, running Linux or Windows 3.1 operating system, the latter from Microsoft Corporation, and remote service application programs developed using the REST application framework currently under development by Ricoh Corporation. A preferred embodiment of classes of objects in the REST framework, described below, are written in C++.

FIG. 1 is representative of but one type of system for embodying the present invention. It will be readily apparent to one of ordinary skill in the art that many system types and configurations are suitable for use in conjunction with the present invention.

Framework Description

FIG. 2 illustrates a block diagram of an object-oriented application framework as used in a preferred embodiment of the present invention. The application layer 140 is the portion of the system consisting of application programs run by an end user, including Remote Setting 100 and Customer Database Access 130, and application programs run automatically by the operating system, including Call-out 110 and Call-in 120.

The core layer 190 consists of a library of class declarations and implementations that provide functions shared by all remote service applications residing in application layer 140 of the framework, including graphical user interface functions 150, general programming-system functions 160, modelling remote machines 170, and communicating with remote machines 180.

The interface layer 260 contains classes ("device drivers") that provide an interface to specific local communication devices such as modems, classes ("protocol drivers") that provide an interface to the communication protocols required to communicate with and operate upon specific families of remote machines (e.g. copiers 200 and facsimile machines 240), as well as interfaces to remote or local database servers 220, and files 230, 240, 250 ("machine description files") that contain descriptions of the services provided by specific types of remote machine. The application programming interface (API) of the classes in the interface layer 140 is defined by abstract classes in the core layer 190; hence an application programmer is insulated from the details of specific interface devices and remote machines.

An application programmer using the framework implements remote service application programs, typically by using a text editor to copy and modify one or more of the existing sample programs in the application layer 140. Applications constructed in this way share a common, well-proven architecture and design, and a large body of re-usable code; eliminating most of the design and debugging phase from the software life-cycle is one way in which the use of an object-oriented application framework speeds up the implementation of remote service applications.

A program that uses the present invention to communicate with a remote machine is capable of communicating with almost any remote machine.

Sample Application Program and File Description

FIG. 3 illustrates some of the sample application programs in application layer 140 of the framework (FIG. 2) and the files whereby they communicate information. All application programs and files preferably reside in the Mass Storage Device 60 of the Computer System 1.

The user interacts directly with a Customer Database Access application 300, a Job Scheduler application 370, and a Remote Setting application 400. (It will be clear to one skilled in the art that many other interactive programs are possible; these are merely illustrative examples.)

The Customer Database Access application 300 allows the user to query a customer database 310 to select machines with which to communicate; it also allows the user to select groups of machines (each described in a Machine Group file 350) and groups of service items (each described in a Service Item Group file 340) upon which to operate. The Customer Database Access application 300 outputs a Job Item file 320 and a Case file 330, each containing the filenames of the other files involved in the interaction.

The user then runs the Job Scheduler application 370, which reads Job Item files 320 and automatically runs instances of the Call Out application 380 and Remote Setting application 400 in order to communicate with one or more Remote Machines 90. The Call In application 390 may be run at any time in response to an incoming communication from a remote machine 90.

The Call In application 390 and Call Out application 380 write a Data Dump file 410 which contains a copy of the information sent by a remote machine 90 to the Call In application or retrieved from a remote machine 90 by the Call Out application 380. The Data Dump file 410 is translated by the Call Translator application 440 into either a Case file 420 or a Comma-Delimited file 450 for import into an Analysis Database 460 or other application program such as a spreadsheet. The Call Translator application 440 performs its conversion operation using a description of the remote machine 90 contained in one of a plurality of Machine Model files 430.

The Remote Setting application 400 is used for direct interactions between a user and some remote machine 90; the operations that can be performed on the remote machine 90 are described in one of a plurality of Machine Model files 350; the access information (e.g. telephone number) of the remote machine 90 and some of the operations to be performed on it may be specified in a Case file 330, or entered directly by the user.

2. Machine Model Module

2.1. Overview

The Machine Model module 170 in FIG. 2 is the main module within the Core Layer 190. The objective of the machine model module is to describe the services available on remote machines to remote service applications in the form of configurations of objects, called Machine Models, and to contain and organize the information required for the application program to keep track of the current state of the remote machine and of any operations and data transfers requested by the user.

In a preferred embodiment of the present invention, the machine and service class hierarchies consist of the following (note indentation denotes inheritance):

    ______________________________________
    Component     Describes a remote machine
    Service
    ServiceCollection
                    Collection of service items
    SC.sub.-- ServiceModel
                      A Component's model
    SC.sub.-- AppServices
                      A Component's application
                      items
    SC.sub.-- Queue   A collection of
                      SI.sub.-- QueueItems
    (and other various other special-purpose
    collections)
    SI.sub.-- ServiceItem
                    Describes a remote service
    SI.sub.-- ModelItem
                      machine model---description
                      only
    SI.sub.-- GuiItem a GUI element representing
                      an item
    SI.sub.-- AppItem application state for an
                      item
    SI.sub.-- QueueItem
                      a queued read or write on
                      an item
    ______________________________________

    ______________________________________
    SI.sub.-- ModelItem
                  machine model---description only
    SI.sub.-- InternalItem
                    internal to application
    SI.sub.-- ExternalItem
                    external storage or server
    SI.sub.-- DirectoryItem
                      directory
    SI.sub.-- FileItem
                      file
    SI.sub.-- TableItem
                      database table
    SI.sub.-- QueryItem database query
    SI.sub.-- TupleItem
                      database tuple
    SI.sub.-- FieldItem
                      database field
    SI.sub.-- RemoteItem
                    remote machine
    SI.sub.-- MemoryItem
                      stored in remote memory
    SI.sub.-- BitfieldItem
                        bitfield in word
    SI.sub.-- ProgramItem
                      accessed by remote program
    ______________________________________

    ______________________________________
    SC.sub.-- ServiceModel: (.linevert split.
    name=k50
    .linevert split.
    SI.sub.-- MemoryItem: (.linevert split.
    name=R17D4
    defaultValue=BCD1:51
    description=`drmk50.dat#R17D4`
    itemValueList=›!
    features=S.sub.-- FeatureSet: (SYSTEM
              RemoteSetting)
    readOnly=-
    msbFirst=+
    isremote=+
    bitOffset=0
    offset=6100
    label=`NCU 13`
    .linevert split.)
    SI.sub.-- MemoryItem: (.linevert split.
    name=R17D5
    defaultValue=BCD1:256
    description=`drmk50.dat#R17D5`
    itemValueList=›!
              features=S.sub.-- FeatureSet: (SYSTEM
              RemoteSetting)
    readOnly=-
    msbFirst=+
    isremote=+
    bitOffset=0
    offset=6101
    label=`NCU 14`
    .linevert split.)
    SI.sub.-- MemoryItem: (.linevert split.
    name=R17D6
    defaultValue=BCD1:256
    description=`drmk50.dat#R17D6`
    itemValueList=›!
    features=S.sub.-- FeatureSet: (
              SYSTEM
              RemoteSetting)
    readOnly=-
    msbFirst=+
    isremote=+
    bitOffset=0
    offset=6102
    label=`NCU 15`
    . . .
    ______________________________________

    ______________________________________
    SC.sub.-- ServiceModel: (.linevert split.
    name=FT8780
    .linevert split.
    SI.sub.-- CopierItem: (.linevert split.
    name=LampThermistor
    writeDcode=`1302;`
    features=S.sub.-- FeatureSet: (
              ReadOnly
              RemoteSetting)
    msbFirst=-
    writeInfCode=`16040070101`
    isremote=+
    offset=0
    label=LampThermistor
    separator=`;`
    IDCode=›!
    defaultValue=Nchars2:"00"
    size.sub.-- for.sub.-- specify.sub.-- data.sub.-- length=2
    description=›!
              readOnly=-
    bitOffset=0
    readInfCode=`16040070101`
    size=2
    readDCode=`1302;`
    .linevert split.)
    SI.sub.-- CopierItem: (.linevert split.
    name=SC.sub.-- ChargerLeak
    writeDCode=`1302;`
    features=S.sub.-- FeatureSet: (
              RemoteSetting
              ScCall)
    msbFirst=-
    writeInfCode=`32000930201`
    isremote=+
    offset=0
    label=SC.sub.-- ChargerLeak
    separator=`;`
    IDCode=›!
    defaultValue=Nchars1.sub.-- 1:"0"
    size.sub.-- for.sub.-- specify.sub.-- data.sub.-- length=2
    description=›!
    readOnly=-
    bitOffset=0
    readInfCode=`32000930201`
    size=1
    readDCode=`1302;`
    .linevert split.)
    SI.sub.-- CopierItem: (.linevert split.
    name=FusingTempADJ
    writeDCode=`1304;`
    features=S.sub.-- FeatureSet: (
              ReadWrite
              RemoteSetting)
    msbFirst=-
    writeInfCode=`51011050101`
    isremote=+
    offset=0
    label=FusingTempADJ
    separator=`;`
    IDCode=›!
    defaultValue=Nchars3s.sub.-- 16:"+00"
    size.sub.-- for.sub.-- specify.sub.-- data.sub.-- length=2
    description=›!
    readOnly=-
    bitOffset=0
    readInfCode=`51011050101`
    size=1
    readDCode=`1302;`
    .linevert split.)
    . . .
    ______________________________________

    ______________________________________
    class Service: public R.sub.-- Nameable {
    Description:
    R.sub.-- ABSTRACT(Service, R.sub.-- Nameable);
    public:
    Pseudo-Attributes:
    R.sub.-- FUNC.sub.-- RX(Service *, parent);
    R.sub.-- CONTAINER.sub.-- IS(parent);
                The parent of this service in the
                tree. Null if this Service is at the
                root of the Service tree (i.e. its
                parent is a Component). "parent" can
                either be set when the Service is
                created, or by the parent itself when
                the child is appended to it.
    R.sub.-- FUNC.sub.-- RO.sub.-- RC(R.sub.-- Collection, children);
    R.sub.-- CONTENTS.sub.-- IS(children);
                A collection to hold the children of
                this service. It is put here so that
                it can be initialized and deleted in
                one place. The downside of this is
                that downcasting has to be done in
                the subclasses in order to
                specialize.
    virtual void  setValueAt(Rcard i, Rvalue const
    &nv);
    virtual void  setValueOf(RKey const &key, Rvalue
    const & nv);
    virtual void  append(Rvalue const &nv);
                  Override the operations that add
                  children, so they can call parentSet.
    virtual Service
                  *getChildByName(R.sub.-- Symbol *nm);
                  Given a service name, find a child
                  that matches it. Should be
                  overridden in subclasses that can do
                  fast lookup.
    virtual Component *component() const;
                The component to which this service
                is attached, if any. Declaration of
                the contents is deferred until it can
                be strongly typed. This is done with
                "S.sub.-- TYPED.sub.-- CHILDREN(child.sub.-- type,
                collection.sub.-- type)"
    #define S.sub.-- TYPED.sub.-- CHILDREN(childType, collectionType).backslas
    h.
    R.sub.-- CONTENTS.sub.-- INIT.sub.-- NEW(collectionType,
    children);.backslash.
    R.sub.-- CHILDREN.sub.-- ARE.sub.-- TYPED(childType, collectionType,
    parentSet)
    Constructors:
    Service(R.sub.-- Symbol &nm, Service *prnt = 0);
              By convention, all ServiceItem
              constructors take a reference to a name as
              their first argument, and an optional
              pointer to a parent as their last
              argument.
    Usage:
    "parent.append(new Service(name, &parent))"
    Service(R.sub.-- Base const &o);
                When constructing a service using its
                copy constructor, we are typically
                building a tree from the bottom up
                and so do not know the parent. It
                has to get assigned on append, which
                we do with parentSet.
    Destructor:
    .sup..about. Service();
                Delegated Collection Operations:
                operations that append a service to a
                parent service have to set the
                child's "parent" field if necessary.
    ______________________________________

    ______________________________________
    class SI.sub.-- ServiceItem: public Service {
    Public:
    S.sub.-- TYPED.sub.-- CHILDREN(SI.sub.-- ServiceItem,
    RT.sub.-- Table<SI.sub.-- ServiceItem>);
                  Returns information about this
                  service item: This information
                  is used to describe this service
                  item to the application
                  (features) and to the user
                  (label, description).
    R.sub.-- ATTR.sub.-- XX.sub.-- RC(R.sub.-- String, label);
                A string used to display label this
                ServiceItem for presentation to the
                user. It the default name and may be
                different from the name because of
                application-specific renaming or
                language translation.
    R.sub.-- FUNC.sub.-- GET(R.sub.-- String *, description);
                  A string that gives a brief
                  description of what this
                  ServiceItem does. In general,
                  the description will be looked
                  up in a database or file rather
                  than being stored in the
                  application's working memory
                  before it is needed.
    R.sub.-- FUNC.sub.-- GET(S.sub.-- FeatureSet*, features);
                Returns a set of symbolic features
                for this service.
    R.sub.-- FUNC.sub.-- GET(Rcard, offset);
                Returns the address of this item (in
                bytes) relative to its parent.
    R.sub.-- FUNC.sub.-- GET(Rcard, bitOffset);
                Returns the offset in bits of this
                item relative to the low order bit of
                the item that contains it, if any.
    R.sub.-- FUNC.sub.-- GET(Rcard, index);
                The index of this item in its parent,
                if the parent is an array of
                identical items. Zero otherwise.
    R.sub.-- FUNC.sub.-- GET(Rcard, address);
                The absolute address of the item (in
                bytes) relative to the start of the
                memory, file, or whatever that
                normally contains it. Computed from
                offset, index, and size.
    Value Description Information:
    The following functions are normally delegated to a
    descriptor, specifically the value descriptor of defaultValue.
    A few functions such as the sizes and valueList, can be
    overridden by attributes in SI.sub.-- ModelItem.
    R.sub.-- FUNC.sub.-- GET(Rvalue, defaultValue);
                The item's default value, if any. The
                default value's R.sub.-- ValueDscr is the
                descriptor used for all instances of
                this item.
    R.sub.-- FUNC.sub.-- GET(R.sub.-- ValueDscr&, defaultDscr);
                The default value descriptor. Should
                be identical to
                "defaultValue().dscr()," but deferred
                for efficiency (i.e. so the user does
                not wind up passing the whole value
                around through several levels of
                indirection).
    R.sub.-- FUNC.sub.-- GET(Rcard, minSize);
    R.sub.-- FUNC.sub.-- GET(Rcard, maxSize);
                The minimum and maximum number of
                bytes required to hold an item's
                value, i.e., to store the item in the
                remote machine's memory, to transmit
                it to the machine, or to store it in
                a database.
                A maxSize of Rinvalidindex indicates
                a variable-length object with no
                upper bound on its size.
    R.sub.-- FUNC.sub.-- GET(Rcard, packedSize);
                The number of bits required to hold
                the item's value.
    R.sub.-- FUNC.sub.-- GET(Rcard, minWidth);
    R.sub.-- FUNC.sub.-- GET(Rcard, maxWidth);
    R.sub.-- FUNC.sub.-- GET(Rcard, minHeight);
    R.sub.-- FUNC.sub.-- GET(Rcard, maxHeight);
                The minimum and maximum number of
                characters and lines required to
                represent a value as a string for
                printing or display.
    R.sub.-- FUNC.sub.-- GET(Rvalue, minValue);
    R.sub.-- FUNC.sub.-- GET(Rvalue, maxValue);
                The item's minimum and maximum
                values. Return Rnullvalue for
                string-valued items.
    R.sub.-- FUNC.sub.-- GET(Rvalue, unit);
    R.sub.-- FUNC.sub.-- GET(Rvalue, scaleFactor);
                A unit and scale factor to be
                displayed after the item's value.
                For example, a voltage's unit and
                scale factor might be V and 1000 for
                a value expressed in kilovolts.
    R.sub.-- FUNC.sub.-- GET(R.sub.-- Base *, valueList);
                The permissible values for an item
                with a small set of named values. It
                should be a collection indexed by
                numeric value and keyed by symbolic
                name.
    R.sub.-- FUNC.sub.-- GET(Rbool, msbFirst);
                Byte ordering.
    R.sub.-- FUNC.sub.-- GET(Rbool, readOnly);
                True if the item cannot be modified
                on the remote machine.
    ______________________________________

    ______________________________________
    class SI.sub.-- ModelItem: public SI.sub.-- ServiceItem {
    R.sub.-- ABSTRACT(SI.sub.-- ModelItem, SI.sub.-- ServiceItem);
    public:
    R.sub.-- String *descriptionInit();
                Initialize the description.
    R.sub.-- ATTR.sub.-- RW.sub.-- RC(S.sub.-- FeatureSet, features);
                The features of this item.
    R.sub.-- ATTR.sub.-- RO(Rcard, offset);
                The address of this item relative to
                the start of machine memory or the
                file or protocol buffer that normally
                contains it.
    R.sub.-- ATTR.sub.-- RO(Rcard, bitOffset);
                The offset in bits of this item
                relative to the low order bit of the
                item that contains it, if any.
    Value Description Information:
                Most value descriptor attributes are
                delegated one more level to a
                ValueDescriptor; some can be
                overridden here if necessary.
    R.sub.-- ATTR.sub.-- RO(Rvalue, defaultValue);
                The item's default value, if any.
                The default value's descriptor is the
                descriptor used for all instances of
                this item.
    R.sub.-- FUNC.sub.-- GET(R.sub.-- ValueDscr&, defaultDscr);
                The descriptor of the default value.
    R.sub.-- ATTR.sub.-- RW(RBool, msbFirst); Byte ordering.
    R.sub.-- ATTR.sub.-- RW.sub.-- RC(R.sub.-- Base, itemValueList);
    R.sub.-- FUNC.sub.-- GET(R.sub.-- Base *, valueList);
                A local value list that can override
                the one in the descriptor.
    R.sub.-- ATTR.sub.-- RW(Rcard, itemSize);
                A local override for size; either in
                bits or bytes depending on whether
                the item is a bitfield or a string.
    R.sub.-- FUNC.sub.-- GET(RCard, minSize);
    R.sub.-- FUNC.sub.-- GET(RCard, maxSize);
    R.sub.-- FUNC.sub.-- GET(RCard, packedSize);
    Reading and Writing:
    SI.sub.-- RemoteItem contains operations for reading and
    writing the item on a remote machine, however these are
    overridden in the protocol-specific subclasses. These
    operations are incorporated to SI.sub.-- ModelItem because this is
    the class an SI.sub.-- AppItem refers to. There is no reason why
    SI.sub.-- AppItem should have to treat remote items and database
    items differently---for example, some machines may be able to
    report their own serial numbers, while others may have serial
    numbers only on the nameplate and in the customer database.
    Note that the remote access operations take an
    SI.sub.-- AppItem argument; this is the application item on behalf of
    which the work is being done. All operations return
    immediately, if the SI.sub.-- AppItem is marked  "busy" a callback
    method is invoked when the work is actually done.
    R.sub.-- FUNC.sub.-- GET.sub.-- IS(RBool, readOnly, rFalse);
    R.sub.-- FUNC.sub.-- GET.sub.-- IS(RBool, isRemote, rFalse);
                true if the service is actually
                contained on a remote machine. This
                can be used as a hint to warn the
                user that performing the read or
                write may take some time.
    virtual RBool updateParentNewValue(SI.sub.-- AppItem *,
    RValue const &);
                Update the appItem's parent's
                newValue if necessary
    virtual RBool updateChildrenNewValue(SI.sub.-- AppItem *,
    RValue const &);
                Update the appItem's childrens'
                newValue if necessary
    virtual RBool updateParentCurrentValue(SI.sub.-- AppItem *,
    RValue const &);
                Update the appItem's parent's
                currentValue if necessary
    virtual RBool updateChildrenCurrentValue (SI.sub.-- AppItem
    *, RValue const &);
                Update the appItem's childrens'
                currentValue if necessary
    virtual void readOrEnqueue(SI.sub.-- AppItem *app, RBool
    mayQueue);
    virtual void writeOrEnqueue
                        (SI.sub.-- AppItem *app,
                        RValue const &v, RBool
                        mayQueue);
                read or write the AppItem's current
                value. If isRemote() and mayQueue are
                both true, the operation will
                actually be queued.
    virtual void readNotify
                      (SI.sub.-- AppItem *app, RValue
                      const &v, R.sub.-- Symbol
                      *status);
    virtual void writeNotify
                      (SI.sub.-- AppItem *app, RValue
                      const &v, R.sub.-- Symbol
                      *status);
                Notify the application item that a
                value has been read or written, with
                the appropriate status (null means
                that all went well). This is what
                actually stores the value in the
                AppItem.
    virtual void readEnqueue(SI.sub.-- AppItem *app);
    virtual void writeEnqueue(SI.sub.-- AppItem *app, RValue
    const &v);
                Make a queue entry.
    virtual void readValue(SI.sub.-- AppItem *app);
    virtual void writeValue(SI.sub.-- AppItem *app, RValue
    const &v);
                Actually perform the read or write,
                and notify the AppItem accordingly.
                May be called from a queue entry.
                The default is for readValue to
                return the ModelItem's defaultValue,
                and for writeValue to notify the
                AppItem that the value has been
                written.
    virtual RCard readValueFromBuffer
                          (SI.sub.-- AppItem *app,
                          R.sub.-- Buffer const
                          &buf, RCard
                          buf.sub.-- addr = 0,
                          Rcard hdr.sub.-- size = 0);
    virtual RCard writeValueIntoBuffer
                          (SI.sub.-- AppItem *app,
                          RValue *const &v,
                          R.sub.-- Buffer &buf,
                          RCard buf.sub.-- addr = 0,
                          RCard hdr.sub.-- size = 0);
                Perform the read or write on a
                buffer, and notify the AppItem.
                  The buf.sub.-- addr parameter is the
                  starting address of the {.backslash.em
                  buffer} relative to the
                  machine's memory location zero;
                  hdr.sub.-- size is the location in the
                  buffer corresponding to
                  buf.sub.-- addr, less any protocol
                  header information.
    Initialization:
    virtual void initAppItem(class SI.sub.-- AppItem *,
    RValue&). {};
                Called when an SI.sub.-- AppItem is created,
                in case the AppItem's current value
                needs to be initialized. The routine
                is given direct access to the current
                value.
    ______________________________________

    ______________________________________
    class SI.sub.-- RemoteItem: public SI.sub.-- ModelItem {
    R.sub.-- ABSTRACT (SI.sub.-- RemoteItem, SI.sub.-- ModelItem);
    public:
    R.sub.-- ATTR.sub.-- GET.sub.-- IS(RBool, isRemote, rTrue);
    R.sub.-- ATTR.sub.-- RW(RBool, readOnly);
    Constructors:
    SI.sub.-- RemoteItem(R.sub.-- Base const &o);
    SI.sub.-- RemoteItem(R.sub.-- Symbol &nm, RValue const &dflt,
    Service *prnt = 0).
    ______________________________________

    ______________________________________
    class SI.sub.-- MemoryItem: public SI.sub.-- RemoteItem {
    R.sub.-- CONCRETE(SI.sub.-- MemoryItem, SI.sub.-- RemoteItem);
    public:
    Attributes:
    R.sub.-- FUNC.sub.-- GET.sub.-- IS(RCard, start, address());
                  starting address.
    Reading and Writing:
    virtual RBool updateChildrenNewValue(SI.sub.-- AppItem *,
    RValue const &);
    virtual RBool updateChildrenCurrentValue(SI.sub.-- AppItem
    *, RValue const &);
    Constructors:
    R.sub.-- COPY.sub.-- CONSTRUCTOR SI.sub.-- MemoryItem
    (R.sub.-- Base const &o);
    SI.sub.-- MemoryItem
                  (R.sub.-- Symbol &nm, RValue const &dflt,
                  RCard addr = 0, Service *prnt = 0);
    SI.sub.-- MemoryItem
                  (R.sub.-- Symbol &nm, RValue const &dflt,
                  RCard byteAddr, RCard bitAddr,
                  Service *prnt = 0).
    ______________________________________

    ______________________________________
    class SI.sub.-- BitfieldItem: public SI.sub.-- MemoryItem {
    R.sub.-- CONCRETE(SI.sub.-- BitfieldItem, SI.sub.-- RemoteItem);
    public:
    R.sub.-- FUNC.sub.-- GET(RCard, minSize);
    R.sub.-- FUNC.sub.-- GET(RCard, maxSize);
    R.sub.-- FUNC.sub.-- GET(RCard, packedSize);
                These have to be overridden in order
                to compute size correctly when
                itemSize is non-zero.
    virtual void readOrEnqueue(SI.sub.-- AppItem *app, RBool
    mayQueue);
    virtual void writeOrEnqueue
                (SI.sub.-- AppItem *app, RValue const &v,
                RBool mayQueue);
    virtual void readEnqueue(SI.sub.-- AppItem *app);
    virtual void writeEnqueue
                (SI.sub.-- AppItem *app, RValue const &v);
    virtual RBool updateParentNewValue
                (SI.sub.-- AppItem *, RValue const &);
    virtual RBool updateParentCurrentValue
                (SI.sub.-- AppItem *, RValue const &).
    ______________________________________

    ______________________________________
    SI.sub.-- DeviceCallBack
    SI.sub.-- CommunicationSession
    SI.sub.-- BufferedSession
                     buffered session
    SI.sub.-- MemorySession
                       memory based session
            SI.sub.-- 256BytesSession
                         256bytes per call
                         session
    SI.sub.-- CopierSession
                       program based session
    SI.sub.-- UnBufferedSession
                     unbuffered session
    SI.sub.-- DBSession
                       data base session
            SI.sub.-- CustAccessSession
                         customer data
                         base access
    SI.sub.-- HistorySession
                       history db
    TI.sub.-- TaskItem
    TI.sub.-- CommunicationItem
                     communication task item
    TI.sub.-- MemoryItem
                       memory based task item
    TI.sub.-- ProgramItem
                       program based task
                       item
    TI.sub.-- HistoryItem
                       data base task item
    ______________________________________

    ______________________________________
    CM.sub.-- CommunicationDevice
    CM.sub.-- Modem
                  modem
    CM.sub.-- CCA Communication adapter for a FAX
    CM.sub.-- USACCA . . .
                  adapter for 256-byte protocol
    CM.sub.-- LADP
                  Line adapter/multiplexer
    CM.sub.-- DBACESS
                  device for a database
    CM.sub.-- DeviceManager
    ______________________________________

• Inventors
  Hart, Peter E.; Jeng, Tina L.; Roth, Rithy K.; Savitzky, Stephen R.; Golding, Richard;
• Assignee
  Ricoh Company, Ltd. (Menlo Park, CA)
• Published
  Nov-3-1998
• Current US Classes:
  719/316
• Application #
  504039
• International Classes
  G06F 009/40
• Field of Search
  395/683
• Examiner
  Butler; Dennis M.
• Agent
  Townsend and Townsend and Crew LLP
• US Patent References:
  4407016
  5168441
  5297279
  5371895
  5404529
  5421009
  5453933
  5457797
  5475845
  5499368
  5548723
  5568639
  5583983
  5606700