8.2 Host Interface

THE FOLLOWING SECTIONS DESCRIBE THE METHODS OF THE HOST INTERFACE.

8.2.1 generateUID() : UID

Returns a newly created DICOM UID that the Hosted Application might use, e.g., to create new data objects and structures.

This method may be called at any time.

8.2.2 getAvailableScreen(appPreferredScreen : Rectangle) : Rectangle

The Hosted Application supplies its preferred screen size in the appPreferredScreen parameter. The Hosting System may utilize this information as a hint, but may return a window location and size that best suits the Hosting System’s GUI.

The method returns the window location and size that the Hosting System would prefer that the Hosted Application utilize. However, there are no requirements that the Hosted Application act on that information.

This method may be called at any time.

8.2.3 getOutputLocation(preferredProtocols: ArrayOfString) : String

The method returns a URI that a Hosted Application may use to store output that it may provide back to the Hosting System (e.g. in response to a getData() call).

The Hosted Application indicates, in order of preference, the protocols it can use to store data. The Hosted Application shall at least support both the http: and the file: protocols. The Hosting System selects the most appropriate protocol, potentially taking into account system or security considerations as well as the order of preference. The Hosting System uses the selected protocol in setting up the resources and generating the URI returned to the Hosted Application.

Notes: 1. There may be limitations when using the http: protocol when compared to the file: protocol. Some functions that might work with a file: protocol such as seek, rewrite, and delete, may not work with the http: protocol. The Hosted Application should assume that it can only write once in sequential order when the returned output location uses the http: protocol.

2. If any authentication information is needed in order to access the data, this authentication information may be included in the URI.

The Hosting System shall keep the URI active while the Hosted Application is in any state other than IDLE or EXIT, or until such time that the Hosted Application returns the URI to the Hosting System (e.g. in an ObjectLocator returned to the Hosting System in response to a getData() call). The disposition of the data that the Hosted Application sends to this URI is the responsibility of the Hosting System after the Hosted Application transitions to the IDLE state or after the Hosted Application returns the URI to the Hosting System (e.g. in an ObjectLocator returned to the Hosting System in response to a getData() call). After the Hosted Application transitions to IDLE state, the Hosting System need not keep the URI active.

The Hosted Application shall only call this method if the Hosted Application is at the INPROGRESS or COMPLETED states.

8.2.4 notifyStateChanged(state : State) : void

The Hosted Application shall invoke this method each time the Hosted Application successfully transitions to a new state. The new state is passed in the state parameter.

Note: While all Hosting Systems need to accept this interface call method, they may track the current Application State in other ways, such as by polling for the state using the Application getState() method.

8.2.5 notifyStatus(status : Status) : void

The Hosted Application may inform the Hosting System of notable events that occur during execution by invoking this method, passing the information in the status parameter.

Note: The Hosting System typically would log these events to facilitate debugging. It may, at its discretion, display the information to the user.

This method may be called at any time.