nsfdata Package: Overview

The nsfdata package is a set of classes made for dealing with NSF data in a lower-level way than the standard classes. There are currently two main conceptual components to it: a set of NSF* interfaces to represent the conceptual objects, the impldxl package that provides classes to deal with raw-format DXL and the structs package that provides Java representations of many Notes C API structures.

Interfaces

The NSF* interfaces are similar to the equivalent org.openntf.domino classes but are not (yet, at least) intended to replicate the full functionality of the normal API. Instead, they are intended to provide uniform access to low-level NSF data from DXL and potential future sources.

DXL Implementation

The impldxl package provides classes that allow reading in a raw-format DXL-exported database and treating it as a collection of notes. As much as possible, it attempts to present the DXL file in a way that is conceptually consistent with a real NSF, though some attributes (like item sequence numbers) are not represented in DXL. Raw item data in these files is contained as BASE64-encoded byte arrays matching the structures used by the C API, in little-endian format.

A DXL file can be read from an InputStream using the constructor for org.openntf.domino.nsfdata.impldxl.DXLDatabase:

NSFDatabase database = new DXLDatabase(is);

This class provides access to the notes in a database. For example, each note and its items can be iterated via:

for(NSFNote note : database.getNotes()) {
    for(NSFItem item : note.getItems()) {
        // Do stuff here
    }
}

Structs

The structs package contains wrappers for many of the structs from the Notes C API. These classes use Javolution's javolution.io.Struct base class and use java.nio.ByteBuffer for backing storage. Due to this setup, they are intended to be independent of the actual storage mechanism for the data, whether DXL or a future native-C adapter.

The struct classes themselves are mostly strict representations of the underlying C structs, but provide Enum versions for fields when possible and have built-in support for any variable-length data that may follow the structure.

Each class can be instantiated using the empty constructor, but should then be initialized using either init(), which will allocate a new backing buffer, or init(ByteBuffer), which will use an existing buffer for the data. Most struct components should be accessed using the Javolution standard idiom, e.g.:

VIEW_TABLE_FORMAT format = new VIEW_TABLE_FORMAT();
format.init();
format.Columns.set(1);

When possible, Enum-friendly components have getters and setters (eventually) to access their values in a safe way. In these cases, the struct member is marked as Deprecated with a reference to the method to use. Similarly, variable data elements (name strings, file data, etc.) are accessed via getters and setters.

Some logically-related structs also have convenience classes to deal with them as a whole, such as CDResourceFile and ViewFormat.