| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (6 out of 7)

Making Workspaces Proprietary

Making workspaces proprietary confines the behavior of the workspace, its items, and their subworkspaces and items. G2 restricts the functionality of proprietary workspaces so that users cannot:

Transfer items on or off the workspace
Clone items on the workspace
Edit the item configuration of the workspace or items upon the workspace
Edit the instance configuration of any class definitions upon the workspace

In addition to these limits, G2 provides configuration statements that affect only proprietary items. When in effect, such configurations cannot be overridden by any user mode, including administrator mode.

Use proprietary workspaces to:

Hide information from users and provide configurations that cannot be overridden by administrator mode.
Create a proprietary KB that requires special authorization codes from Gensym for users to access it.

Creating a Proprietary KB

A proprietary KB is one that requires special authorization codes from Gensym. You create a a proprietary KB while making proprietary workspaces, by configuring one or more workspaces with a proprietary package name.

To make a proprietary workspace:

Open the attribute table of the workspace to make proprietary by choosing:
Edit the Proprietary-package attribute of the attribute table. This attribute is only available when the KB is in proprietary mode.
Complete the attribute with a proprietary statement.

Entering a Proprietary Statement

In the Proprietary-package attribute, enter the statement for a proprietary workspace using this syntax:

{none | not proprietary | potentially private | potentially package-name }


Proprietary statement	Description
`none`	Indicates that the workspace inherits the value of its superior workspace.
`not proprietary`	Specifies that the workspace is not proprietary. When you direct G2 to make workspaces proprietary, this value changes to `none`.
`potentially private`	Specifies that the workspace is proprietary, but does not require special authorization. The term `private` is a system-defined package name that is always authorized. Once workspaces are proprietary, configuration statements that restrict proprietary items will be in effect.
`potentially` package-name	Indicates the name of the package for which users require authorization to use this KB. Once workspaces are proprietary, this value causes the KB to become proprietary, requiring authorization to access it.

Specifying private for the Proprietary-package attribute on your workspaces lets you protect proprietary information without requiring end users to modify the g2.ok file for authorization. To obtain appropriate authorization codes for a package-name that you provide, end users must call the Production and Licensing Department at Gensym.

Tip: When restricting knowledge, never make a top-level proprietary workspace non-deletable, unless you want to prevent end users from hiding one of your workspaces. Typically, end users may wish to use the parts of the KB that they created in your delivered application. To do this without authorization, they must be able to delete your proprietary workspaces.

Creating and Configuring Proprietary Items

An item is considered proprietary if it resides upon a proprietary workspace.

Making items proprietary is a simple way to limit item behavior within your KB. For example, to make all instances of an AUTOMOBILE class proprietary, do so by making a workspace proprietary, and then placing the AUTOMOBILE class definition upon it. By adding a configuration statement to either the proprietary workspace or the class definition, you could then further restrict the object's behavior.

You enter a configuration for proprietary items, using the restrict proprietary items as follows configuration clause. While you can include this configuration statement in any item's Item-configuration attribute, such statements take effect only if the item, or its definition, resides upon a proprietary workspace, or its subworkspaces or items. For example, if you click on an automobile object residing on a proprietary workspace, and see a configuration statement such as this:

restrict proprietary items as follows: selecting any automobile does nothing

then the configuration is in effect and clicking on the item does nothing. For a detailed description of configuration statements, see Chapter 7, Configurations.

Testing a Proprietary KB Before Completion

Before completing the process of making workspaces proprietary, you can simulate the behavior of your target proprietary KB or workspaces by choosing:

Main Menu > Miscellany > Enter Simulate Proprietary Mode

This option simulates the behavior of your KB as if your computer was authorized to use the named package. You can enter and leave simulate proprietary mode as many times as you need to change the KB behavior until you are satisfied.

To exit from the simulated proprietary mode choose:

Main Menu > Miscellany > Leave Simulate Proprietary Mode

Tip: You do not have to be running the KB in package preparation mode to simulate proprietary mode. You can simulate proprietary mode at any time.

Completing Proprietary Workspaces

To finish making workspaces proprietary:

If you did not save your source KB before starting to make proprietary items, save the KB now for future development.
Pause the KB and choose:
This dialog appears, reminding you that the changes you are about to make are irreversible.
Select OK for G2 to make the marked workspaces proprietary.
Save the target KB using a different name than the source KB, or save the target KB in a different directory. The target KB is the one for distribution.

Leave package preparation mode by choosing:

Main Menu > Miscellany > Leave Package Preparation Mode

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (6 out of 7)

Copyright © 1997 Gensym Corporation, Inc.