WEBSITE ALPHA · AI-assisted, source-reviewed documentation · Full-stack docs reconciled 2026-08-26
64x64base

Open Engine API Reference

Public API boundaries for x64base engine, index, GUI, workspace, memo, and extension integrations.

This page names the public API boundaries the project should protect as the implementation matures. It is not a frozen ABI. It is the policy-level surface for open architecture work.

Core engine API

  • open/close table
  • iterate records
  • get/set fields
  • memo read/write
  • inspect structure and field metadata
  • expose typed errors and diagnostics

Workspace and area API

Workspaces are wrappers over active areas. Each area is a DbArea-style object with table state, cursor state, indexes, relations, field metadata, memo references, and validation context.

The workspace API should expose:

  • create, select, close, save, and load workspace.
  • enumerate areas.
  • inspect active area state.
  • bind relation and index views to area state.
  • run validation against one area or a workspace set.

Open Index API

  • create index
  • rebuild index
  • verify index
  • open/close index environment
  • select active order
  • seek and scoped traversal
  • expose logical CDX/CNX/INX concepts without leaking one physical backend
  • support LMDB-backed lifecycle where applicable
  • report integrity and rebuild diagnostics

The Open Index API is the stable integration boundary for alternate index backends, teaching tools, validation tools, and GUI order selectors.

Open GUI API

The Open GUI API should keep user interface work separate from table mechanics. GUI implementations should call services instead of reimplementing the engine.

Expected service groups:

  • browse table and current work area.
  • inspect field and structure metadata.
  • run DotTalk++ commands and DotScript files.
  • display validation and SelfDoc reports.
  • show index/order state.
  • show relation graphs.
  • edit records through engine validation.
  • synchronize views with workspace and area events.

This boundary allows wxWidgets, Python/Tk, Turbo Vision/TUI, and future frontends to share the same runtime contract.

Python API boundary

The current optional native binding is pydottalk, a pybind11 module over a selected part of the x64base DbArea object model. It exposes table lifecycle, record navigation and inspection, field access, memo readback, and bounded physical CRUD operations. Read-only and disposable-copy CRUD smoke paths exist.

This is not a frozen Python ABI and it is not the DotTalk++ command shell. Workspace, relation, complete index/order semantics, memo mutation, and general command execution must not be assumed unless their Python contracts and proof are added.

The separate pydottalk_api prototype is a local FastAPI/SQLAlchemy bridge used by pycrud. It does not currently expose the native binding over HTTP. See Python Integration: pydottalk, pydottalk_api, and pycrud for the current boundary and possible development path.

Custom field type API

In addition to student code hooks, x64base supports custom field types through a register-once codec registry. A type registers its type code together with a codec (the bytes ↔ text encode/decode pair), a fixed on-disk width, the DBF flavors it is eligible for, and a display name — after which the type flows through CREATE, validation, and storage with no further engine change. The built-in binary types (I/B/Y/T) are defined through this same registry, and a worked custom type ships as a demonstration.

A registered field type provides:

  • a codec: encode a value to its fixed-width on-disk bytes and decode it back.
  • a fixed on-disk width (or a width taken from the CREATE length parameter).
  • flavor eligibility (which DBF flavors may use the type) and a display name.
  • validation, performed through the codec so the type is its own source of truth.
  • documentation metadata for SelfDoc and the Master Documentation Organizer.

Memo API

The memo API should reflect the object-oriented memo model:

  • memo store.
  • memo manager.
  • memo object.
  • memo reference.
  • read/write/update operations.
  • validation and repair diagnostics.

Errors

  • typed errors
  • numeric codes
  • structured diagnostics for script, index, memo, workspace, and GUI boundaries

Integration

  • DotScript command files.
  • native Python binding through the bounded pydottalk surface.
  • local API and GUI experiments through pydottalk_api and pycrud.
  • C-compatible boundary candidates.
  • GUI-neutral service bridge.
  • generated documentation and SelfDoc extraction.
← Identity, Authentication & RBAC
Python Integration →