Vix.cpp v2.7.0

Vix.cpp v2.7.0 introduces three new foundations for building and learning with Vix: Vix Note, Vix UI, and Vix Requests.

Vix Note provides a visual workspace where C++ and Reply cells can be written, executed, saved, and exported. Vix UI introduces a server-rendered interface layer for applications that need views, forms, assets, live fragments, or WebView delivery. Vix Requests adds a built-in HTTP and HTTPS client for communicating with external APIs without introducing a separate networking library into each project.

The release also changes how the Vix SDK is installed. The bootstrap installers now install the CLI only, while developers select the SDK profile that matches their project through vix upgrade --sdk.

These changes give the v2.7 release line a broader application workflow without making every Vix installation carry the complete SDK by default.

Release focus

Vix began as a native runtime and command-line workflow for building C++ applications. As the project grew, several related needs became more visible.

Learning and experimentation required a workspace more approachable than a complete application project. Web and desktop applications needed a clear interface layer rather than ad hoc HTML generation. Applications consuming external services needed a simple client API with proper HTTP, HTTPS, timeout, session, and TLS behavior.

The SDK also needed a more deliberate installation model. A developer building a database application does not necessarily need game, peer-to-peer, desktop, and agent modules. Installing the complete SDK for every project made setup heavier and hid which system dependencies belonged to which domain.

Vix.cpp v2.7.0 addresses these problems together.

The release introduces the modules needed for visual learning, interfaces, and outbound requests, while SDK profiles make it possible to install only the relevant parts of the platform.

Vix SDK profiles

Vix now distributes specialized SDK profiles through:

vix upgrade --sdk

The supported profiles are:

default
web
data
desktop
p2p
game
agent
all

Each profile groups the modules and system dependencies required for a particular kind of project.

The web profile is intended for HTTP services, WebSocket applications, requests, middleware, templates, and related web functionality.

The data profile covers database, ORM, cache, key-value, and data-oriented modules.

The desktop, p2p, game, and agent profiles provide the modules associated with those application domains.

The default profile provides the general SDK foundation, while all installs the complete SDK for development, validation, or projects that intentionally use modules from several areas.

Discovering SDK profiles

Available release profiles can be listed with:

vix upgrade --sdk list

A profile can be inspected before installation:

vix upgrade --sdk info web

The shorter information form is also supported:

vix upgrade --sdk-info web

Profile information includes:

  • a description of the profile;
  • the Vix modules it contains;
  • system dependencies for the current operating system;
  • the command used to install it;
  • a link to the relevant documentation.

This allows developers to understand what an SDK profile contains before downloading it or installing additional system packages.

Installing SDK profiles

A profile can be installed with:

vix upgrade --sdk web

Running vix upgrade --sdk without a profile selects default.

Several profiles can also be installed in one command:

vix upgrade --sdk web data desktop

Each profile reports its status independently. A missing release asset for one profile is shown directly rather than causing the command to finish without useful output.

Profile names are validated before asset resolution, so an unknown profile produces a focused CLI error instead of a failed download request.

SDK installation layout

SDK profiles are installed under:

~/.vix/sdk/<profile>/<version>/

Current-profile metadata is stored in:

~/.vix/sdk/<profile>/current.json

A current pointer is also maintained under:

~/.vix/sdk/<profile>/current

The installation metadata records the profile, Vix version, platform, installation directory, source asset, installation time, and downloaded size.

Keeping versions in separate directories makes the installation state easier to inspect and prepares the SDK workflow for safer upgrades and profile lifecycle management.

CLI-first installation

The Unix and Windows bootstrap installers now install the Vix CLI only.

After installation, the developer selects an SDK from the CLI:

vix upgrade --sdk list
vix upgrade --sdk info web
vix upgrade --sdk web

This separates two responsibilities.

The bootstrap installer is responsible for making the vix command available.

The CLI is responsible for understanding Vix release assets, SDK profiles, operating systems, architectures, system dependencies, and profile metadata.

This avoids duplicating SDK selection logic across shell and PowerShell installation scripts.

The older --cli-only installer option remains accepted for compatibility, although CLI-only installation is now the normal behavior.

Upgrade command experience

vix upgrade now uses a quieter default output focused on the information required by the developer.

Internal commands, temporary paths, clone operations, raw download details, and low-level diagnostics are hidden during a normal successful upgrade.

Detailed output remains available with:

vix upgrade --verbose

Check and dry-run modes use concise summaries:

vix upgrade --check
vix upgrade --dry-run

When checking an SDK profile, Vix verifies that the expected release asset exists instead of reporting that a profile can be installed before confirming its availability.

Machine-readable output is kept separate:

vix upgrade --json

In JSON mode, human progress lines are not mixed into the structured result.

Vix Note

Vix Note is a visual notebook for learning, demonstrating, and experimenting with C++ and Vix.cpp.

It is available as the first-class SDK target:

vix::note

and through the CLI:

vix note

Running the command without a document starts a workspace in the current directory.

An existing notebook can be opened with:

vix note lesson.vixnote

The browser interface provides editable cells, execution controls, outputs, compiler errors, cell ordering, document saving, and run-all behavior.

The .vixnote format

Vix Note documents use the .vixnote extension and remain compatible with Markdown-oriented content.

Cell boundaries and metadata are stored through comments such as:

<!-- vixnote:cell ... -->

This keeps the document readable as text while preserving information required by the notebook, including stable cell identifiers, titles, types, and execution state.

The document model includes:

vix::note::NoteDocument
vix::note::NoteCell
vix::note::NoteResult
vix::note::NoteOutput
vix::note::NoteError

Serialization now preserves stable cell identifiers and titles through load, edit, save, and reload cycles.

Note cell execution

The first Vix Note release supports C++ and Reply execution.

C++ cells run through the existing Vix execution workflow rather than through an unrelated embedded compiler. This allows a note to use the same compiler and project context as ordinary Vix commands.

Reply cells use the embedded Vix Reply runtime.

The runtime session stores cell outputs and execution records so the UI can display the result associated with each cell.

Note execution can also understand the surrounding Vix project. It can use the project root, vix.app, legacy manifests, dependency directories, include paths, and the correct project working directory.

This makes it possible to write notebook examples that use the project’s real headers and dependencies rather than limiting Note to standalone standard-library snippets.

Note workspace mode

A pre-existing .vixnote file is no longer required.

Running:

vix note

starts a Note workspace rooted in the current directory.

This is useful when beginning a lesson, exploring an existing project, or testing small pieces of code without first creating a document manually.

A document can then be created and saved from the browser interface.

The workflow is similar to other notebook environments while remaining connected to the native Vix project and compiler.

Note API and local server

Vix Note starts a local server that hosts the interface and exposes the notebook operations required by the frontend.

The initial API supports:

  • loading document state;
  • editing cells;
  • executing one cell;
  • executing all cells;
  • moving cells;
  • saving the document;
  • retrieving execution results and errors.

The frontend uses these routes rather than maintaining an unrelated in-browser document model.

The server also handles static assets for the Note interface.

Note UI assets

Vix Note can load its frontend assets from several sources.

It supports project-local assets, installed assets, a custom asset directory, and an embedded fallback.

A custom directory can be supplied through:

VIX_NOTE_ASSET_DIR=/path/to/assets vix note

The embedded fallback ensures that Note can still start when an external asset directory is unavailable.

Asset resolution covers both / and /index.html, and the server tests validate normal, installed, custom, and fallback asset behavior.

Desktop Note mode

Vix Note can run inside a desktop WebView shell:

vix note --desktop

An existing notebook can be opened similarly:

vix note lesson.vixnote --desktop

The Note server runs locally in the process, while the desktop shell opens the interface after the readiness endpoint becomes available.

The shell waits for the configured server URL instead of opening immediately and displaying an unavailable page.

The browser workflow remains the default. Desktop mode provides another delivery path for environments where the notebook should feel like a standalone local application.

Static HTML export

A .vixnote lesson can be exported as static HTML:

vix note export lesson.vixnote --out lesson.html

The export produces a document that can be opened without starting the Note server.

This is useful for sharing lessons, publishing examples, archiving completed notebooks, or distributing educational content where interactive execution is not required.

Vix UI

Vix UI introduces a server-rendered interface layer for Vix applications.

It is available through:

#include <vix/ui.hpp>

and through the CMake target:

vix::ui

The module builds on the existing Vix template engine and HTTP response layer rather than introducing a separate client-side application framework.

Its purpose is to provide the common primitives needed to generate application interfaces from C++ in a structured way.

Views and responses

The core UI types include:

vix::ui::View
vix::ui::ViewContext
vix::ui::ViewResult
vix::ui::HtmlResponse

A view describes server-rendered content and receives the context required to produce its result.

HtmlResponse allows the HTTP layer to return UI output directly without requiring every route to construct low-level response bodies and headers manually.

Core now supports optional UI response integration, so applications can return Vix UI views through the normal routing workflow when the UI module is enabled.

HTML helpers

Vix UI includes helpers for common HTML generation tasks.

These cover escaping text, creating attributes, and producing small fragments without repeatedly rebuilding the same safety logic inside each application.

The helpers are intended for focused rendering tasks. Larger page structures can continue to use the template system and view abstractions.

Escaping remains explicit because server-rendered output must distinguish trusted markup from user-provided text.

Asset management

The UI asset layer includes:

Asset
AssetManifest
AssetManager
AssetMap
AssetMode

It supports development and production asset behavior, including:

  • manifest lookup;
  • hashed production asset paths;
  • CSS and JavaScript grouping;
  • preload generation;
  • module scripts;
  • asset versioning.

This allows a server-rendered application to use assets produced by a frontend build tool without hardcoding generated filenames into C++ source.

In development, readable or direct paths can be used. In production, the asset manager can resolve the fingerprinted paths recorded by the build manifest.

Forms

Vix UI provides server-rendered form helpers for:

  • text fields;
  • select options;
  • checkboxes;
  • radio buttons;
  • file inputs;
  • form data binding;
  • previous submitted values;
  • validation errors;
  • CSRF-related fields.

The goal is to keep ordinary server-rendered forms practical without creating a large form framework.

A validation failure can return the same view with the user’s earlier input and associated errors, instead of requiring each project to rebuild that behavior from scratch.

Live fragments and notifications

The module includes helpers for interfaces that update part of a page rather than rendering the complete document again.

This includes support for:

  • fragments;
  • WebSocket-friendly updates;
  • flash messages;
  • toast notifications.

These primitives are designed to work with the existing Vix HTTP and WebSocket stack.

They do not require that the entire application become a client-side single-page application. A project can remain server-rendered while adding live behavior only where it is useful.

PWA and mobile helpers

Vix UI includes helpers for Progressive Web App metadata and mobile-oriented browser behavior.

These cover:

  • viewport metadata;
  • safe-area CSS;
  • web application manifests;
  • installable application meta tags.

The initial mobile direction is based on web interfaces and WebView delivery rather than a separate native widget system.

This keeps one interface model usable in browsers, desktop shells, and mobile shells while leaving space for native UI work where it is genuinely required.

Desktop shell primitives

The UI module includes the lower-level components used by desktop shell workflows:

AppShell
ShellConfig
ServerProcess
ServerReadiness

It also includes a descriptor backend for non-visual validation and a Linux WebView backend for actual desktop windows.

The descriptor backend allows shell behavior to be tested in CI without opening a graphical window.

Platform descriptors describe web, desktop, and mobile targets so higher-level commands can prepare the correct delivery path from one application interface.

Desktop CLI workflow

The CLI now provides:

vix desktop

Development mode can be started with:

vix desktop run

A desktop build can be prepared with:

vix desktop build

A distributable directory can be created with:

vix desktop package --target dir

The shell manages the relationship between the local server process and the WebView.

It waits for server readiness before opening the application and cleans up server processes started by vix desktop run when the desktop shell closes.

Mobile shell workflow

Vix also introduces:

vix mobile

The first mobile implementation generates Android WebView projects.

The workflow includes project generation, wrapper handling, build, run, and device-listing commands.

Generated Android projects include the launcher resources required for a valid build, and commands can be run from inside the generated Android project directory.

When a Gradle wrapper is present, Vix prefers:

./gradlew

over relying on a system Gradle installation.

Launch behavior uses the generated application package and MainActivity.

Vix Requests

Vix Requests provides a built-in HTTP and HTTPS client API.

It is available through:

#include <vix/requests.hpp>

or:

#include <vix/requests/requests.hpp>

The public target is:

vix::requests

The API is designed for direct request workflows while still providing reusable clients and sessions for applications that need persistent configuration.

Basic requests

The module provides helpers for common HTTP methods:

vix::requests::get
vix::requests::post
vix::requests::put
vix::requests::patch
vix::requests::del
vix::requests::head
vix::requests::request

A simple request can use the direct helper API:

#include <vix/requests.hpp>

int main()
{
  auto response = vix::requests::get("https://example.com/api/status");

  if (!response)
  {
    return 1;
  }

  return response->ok() ? 0 : 1;
}

The direct functions are intended for small requests and focused scripts.

Applications that share configuration across several calls can use Client or Session.

Clients and sessions

Client provides a reusable request interface for applications that communicate with one or more services.

Session can preserve shared configuration such as default headers, cookies, authentication, and request behavior across calls.

This avoids repeating the same options for every endpoint while keeping request state explicit.

The module also includes examples for API client wrappers, where application-specific methods are built on top of a configured Vix Requests client.

Request configuration

Requests can include:

  • headers;
  • query parameters;
  • request bodies;
  • redirects;
  • cookies;
  • timeouts;
  • Basic Authentication;
  • Bearer tokens.

Response helpers provide access to status, headers, and parsed body data.

The API is intended to keep ordinary service calls readable while retaining access to lower-level request options when needed.

Asynchronous requests

Asynchronous variants are available for the supported methods:

async_get
async_post
async_put
async_patch
async_del
async_head
async_request

The transport uses vix::async, allowing requests to participate in the existing Vix asynchronous runtime instead of introducing another scheduler or event loop.

This is useful for servers and applications that need to make outbound calls without blocking the active worker.

HTTPS and TLS

Vix Requests supports HTTP and HTTPS transports.

HTTPS uses OpenSSL with Asio-based transport execution.

The implementation includes:

  • TLS handshake support;
  • Server Name Indication;
  • hostname verification;
  • certificate verification enabled by default.

TLS verification is controlled through:

RequestOptions::verify_tls

Verification can be disabled for controlled local testing, but secure verification remains the default for normal requests.

The module includes HTTPS smoke validation through a local OpenSSL test server so TLS behavior can be tested without depending entirely on an external public service.

Build and SDK integration

The new modules are integrated into the Vix umbrella build.

When enabled, the following targets are built, installed, and exported:

vix::note
vix::ui
vix::requests

They can also participate in:

vix::vix

through their corresponding feature options.

Requests adds the umbrella configuration options:

VIX_ENABLE_REQUESTS
VIX_REQUESTS_BUILD_TESTS
VIX_REQUESTS_BUILD_EXAMPLES

Release validation checks that the new public headers and static libraries are present after installation.

This prevents a module from building successfully inside the repository while being absent or incomplete in the distributed SDK.

CI and validation

The release expands CI coverage for Note, UI, and Requests across umbrella builds, module tests, package export, SDK validation, release checks, and security-oriented configurations.

Core is tested with UI support both enabled and disabled so the optional response integration does not become an unconditional dependency.

Vix Requests is built, tested, installed, and consumed through its exported package configuration.

HTTP integration tests run against local test services, while HTTPS behavior is validated through a local OpenSSL server.

Vix Note tests cover document parsing, stable metadata, local routes, cell execution, run-all behavior, asset loading, custom asset directories, save and reload behavior, and workspace startup.

Desktop shell tests use the descriptor backend in automated environments instead of opening a real Linux WebView window.

Mobile validation covers generated Android resources, Gradle wrapper selection, project detection, building, and application launch metadata.

Performance signal

As part of the v2.7.0 validation work, the Vix HTTP runtime was measured with a local benchmark on an HP EliteBook running Linux on x86_64 with eight CPU threads.

The benchmark used wrk against a small local /bench route:

wrk -t8 -c800 -d30s --latency http://127.0.0.1:8080/bench

The server completed:

3,386,276 requests in 30.09s
112,539.11 requests/sec

Recorded latency was:

Average: 7.31ms
p50:     6.51ms
p75:     7.59ms
p90:     8.73ms
p99:    12.19ms

This result is included as a local performance signal for the v2.7 runtime rather than as a universal throughput claim. HTTP performance depends on the application route, compiler, build configuration, operating system, hardware, connection settings, and benchmark methodology.

The benchmark nevertheless confirms that the new Note, UI, Requests, SDK, desktop, and mobile work did not require turning the underlying HTTP runtime into a heavier execution path.

Note fixes

Several issues found during the Vix Note integration were corrected before the release.

Cell identifiers are preserved after editing and saving a notebook.

The command can start from the current directory without an existing note file.

Asset resolution now works across custom directories, environment overrides, installed files, and embedded fallback assets.

Desktop Note mode starts the server in process and waits until it is ready before opening the WebView.

C++ cell execution avoids unnecessary clean rebuilds during ordinary runs, keeping notebook iteration practical.

UI shell fixes

Desktop shell startup now waits for the configured readiness URL before opening.

The shell handles the case where the readiness endpoint is already used by another process rather than blindly starting a duplicate service.

Processes launched by vix desktop run are cleaned up when the shell closes.

Android generation now includes the launcher icon resources needed by the generated application.

Mobile build, run, and wrapper commands recognize the generated project even when invoked from inside its Android directory.

Upgrade fixes

The new SDK workflow also corrects several command-line presentation and validation problems.

Unavailable profile assets are reported directly during dry runs and checks.

Unknown profile names fail before asset lookup.

Multi-profile commands produce visible status for each profile.

Important labels and commands use readable terminal contrast.

Module lists and system dependency commands are formatted as normal readable terminal content rather than low-contrast decorative text.

Extra blank lines before the shell prompt have been removed.

Removed prototypes

The early Vix Note prototype files were removed:

examples/hello.vixnote
examples/learning_cpp.vixnote
examples/vix_ui_note.vixnote

They were replaced by the more complete C++, Reply, and HTML learning examples introduced with the stable Note foundation.

Removing the prototypes avoids keeping examples that describe an earlier document structure or execution model.

Compatibility

Existing Vix projects remain compatible with the release.

The new modules are optional and are included only when enabled by the selected SDK and build configuration.

Projects that do not use UI retain the existing Core HTTP response behavior.

The install scripts continue to make the CLI available, but developers must now select an SDK profile through vix upgrade --sdk when SDK headers and libraries are required.

The --cli-only installer option remains recognized for older automation.

Projects that need the complete SDK can continue to use:

vix upgrade --sdk all

Projects with focused requirements can install a smaller profile instead.

Known limitations

Vix Note v1.0.0 provides the notebook foundation but does not yet include the later package-based extension system. The first release supports the built-in cell and runtime model.

C++ cells execute native code and should be treated with the same care as running a local executable. Stronger timeout and output guards are introduced in v2.7.2.

Vix UI is primarily a server-rendered interface system. It does not attempt to replace full client-side frameworks when an application genuinely requires a large browser runtime.

The Linux WebView backend is the first native desktop shell implementation. Platform support depends on the available shell backend and system libraries.

The initial mobile workflow targets Android WebView projects. It is not a complete cross-platform native mobile toolkit.

Vix Requests provides the common HTTP and HTTPS client workflow, but specialized protocol clients may still require application-specific wrappers.

SDK profiles in this release can be installed side by side, but full automatic composition of modules from several profiles is completed in v2.7.4.

Release summary

Vix.cpp v2.7.0 expands the platform in three clear directions.

Vix Note creates a visual environment for learning, documenting, and running C++ code while remaining connected to real Vix projects.

Vix UI provides the server-rendered primitives needed to build interfaces, forms, asset pipelines, live fragments, PWAs, and WebView-delivered applications.

Vix Requests gives applications a standard way to communicate with HTTP and HTTPS services using direct calls, reusable sessions, asynchronous APIs, and secure TLS defaults.

The new SDK profile workflow makes these capabilities available without requiring every installation to carry the complete platform.

Developers install the CLI first, inspect the available profiles, and then install the SDK that matches the project they are building.

This release establishes the main foundations extended throughout the rest of the v2.7 line: App Modules, module dependencies, Cloud integration, SDK composition, safer package workflows, and package-based Vix Note extensions.