1.     Obelix Client Architecture

1.1     Overview

 Live Picture Foundation library: provides features that are not specific to FITS or FlashPix. Examples are memory management, file i/o, generic pixel buffers, and mathematical operations.

 Imaging modules: These have no knowledge of FITS, but require some features from the Foundation classes.

 FITS rendering and File handling modules

 FITS editing modules

1.2     Reading the Chart: Which modules reference which?

·        Rule: Only a module which rests directly upon another module may access it. (See black arrows.)

·        A generic messaging mechanism acts as a bridge between the Application Model and the User Interface. (See red arrow).[1]

1.3     Which APIs support FlashPix?

Obelix Client will manipulate FlashPix files at two distinct levels:

·        Directly — for image browsing needs — via the FlashPix SDK

·        Indirectly, through the FITS RIP.

1.3.1      FlashPix SDK (C Level API)

This is the high level API of choice for direct manipulation of FlashPix files. Obelix will use this API for all non-FITS related operations (such as viewing thumbnails of files, etc.). As a general principle, always use the highest level API which performs the desired task.

1.3.2      RIImage Classes (C++ API, used by FITS RIP)

The FITS RIP can use any image which follows the RIImage protocol. FlashPix and IVUE are two examples of formats that follow this protocol.

1.3.3      FlashPix Implementation

This is the implementation of the RIImage protocol which is specific to FlashPix.

1.4     Which Obelix modules comprise FITS technology?

1.4.1      FITS Editing modules

These APIs will be developed as part of the Obelix project. These features generally exist in some form within the Live Picture 2.6 , and must be extracted from the application  and made available in library form.

1.4.2      FITS RIP and File IO

These modules exist today. Those interfaces necessary to develop Obelix type applications will be documented as part of the Obelix project.

1.4.3      RIImage Classes with FlashPix Implementation

FITS, by definition, consumes images. FITS understands images as objects which follow the RIImage protocol, for which LPI has a FlashPix implementation.

1.4.4      Live Picture Foundation Library

Both FITS and RIImage rely on low level services provided by the Foundation Library.

1.5     Which Obelix Client modules must be implemented for each platform?

1.5.1      Obelix Application Shell (modify)

1.5.2      Specific UI components (rewrite)

1.5.3      Generic Framework Extensions (reusable for other applications)

 


[1]  This messaging mechanism is provided to solve a specific problem. Pragmatic considerations such as performance and native platform “look and feel” cause us to choose a platform-specific UI framework. Given this necessity, we attempt as a consequence to enlarge the application model (or AM, which is portable), at the expense of the UI (which is tied to the platform). Without this messaging mechanism, something is still missing: If the AM makes no calls to the UI whatsoever, it forces the AM to be divided into many tiny functions, which must still be glued together by non-portable UI components. The generic message approach allows higher level code, including “interactive glue” to be defined in the AM itself. The AM, by broadcasting messages about its actions to unknown “listeners” (in this case, the UI), allows the UI to synchronize with and respond to application model events. In this way, the AM can grow to include very high level functions including a degree of interaction with no investment in the specification, protocol, or implementation of the UI.