What's Next in Kitto^x

This page tracks the planned evolutions of the Kitto^x framework — features that have been designed and analyzed but are not yet shipped. Each item below is the result of a pre-implementation design session and represents a concrete direction for the framework's near-term roadmap.

Roadmap, not commitment

The features described here are design proposals. They are documented in detail in the project repository (KittoX_*.md and UpdateRoutingArchitecture.md files at the repo root) and represent a baseline for upcoming work — not a public commitment to ship within a specific release. Targets and priorities may shift as feedback and requests come in.

At a Glance

Initiative	Type	Audience	Target
Unified Attribute-Based Routing	Architectural refactor	Framework / app developers	Kittox 4.1.x (post ITDevCon 2026)
Server-Push Notifications & Background Jobs	New feature (open core)	End users + framework	TBD
In-App Help Chat	New feature (open core)	End users of Kittox apps	TBD
MCP Server for AI-Driven Development	New feature (Enterprise)	Framework / app developers, AI agents	In progress — base already shipped, see What's New and MCP-KittoX reference

Unified Attribute-Based Routing

The most imminent evolution is architectural, not user-facing: unifying the URL routing layer under the same attribute-based model already used by the three Enterprise data handlers (ChartPanel, CalendarPanel, GoogleMap).

What changes

Today, Kitto^x dispatches requests via two parallel layers:

• Attribute-based (modern) — for kx/view/{V}/chart-data, calendar-data, map-data. Handlers are registered via Delphi RTTI, see Attribute-Based Routing.
• Legacy if/else chain in TKWebApplication.DoHandleRequest (~1500 lines) — for ~16 endpoints including login, view rendering, save/delete, lookup, blob, tool, detail.

The plan is to migrate every legacy endpoint to the attribute model, organized by macro-domain into virtual base classes:

Base class	Endpoints
TKXAuthHandlerBase	kx/login, kx/resetpassword, kx/changepassword
TKXHomeHandlerBase	<app>/ (root, language switching, login redirect)
TKXViewHandlerBase	view/{V}, data, form, save, save-cache, delete
TKXLookupHandlerBase	lookup
TKXBlobToolHandlerBase	blob/{F}, tool/{T}
TKXDetailHandlerBase	detail/{I}/data, save, delete

Once the migration is complete, the body of DoHandleRequest shrinks from ~1500 lines to ~5–10: activate, dispatch via the attribute registry, deactivate.

Why it matters for app developers

The big win for application code is the new RegisterOverride API. Today, customizing a framework endpoint means forking the framework or patching TKWebApplication. After the refactor, an application can override any endpoint by deriving from the base handler class:

type
  TLoginHandlerHello = class(TKXAuthHandlerBase)
  protected
    procedure AfterAuthenticateOK; override;  // add an audit log entry
  end;

initialization
  TKXResourceRegistry.Instance.RegisterOverride(TLoginHandlerHello);

Concrete extension points planned via virtual hooks: BeforeAuthenticate / AfterAuthenticateOK / AfterAuthenticateFail, BuildStore, BuildFilterExpression, OnBeforeSave / OnAfterSave, OnBeforeDelete, BuildLookupQuery, OnToolError, and others.

Filter chain

A second design point is moving cross-cutting concerns (authorization, error handling, session-lost detection) into a request filter chain (IKXRequestFilter with BeforeInvoke / AfterInvoke / OnException hooks). The auth gate becomes one of the standard filters, with an [TKXAnonymous] attribute to opt out specific endpoints (login, password reset). Application-side filters for audit logging, rate limiting, multi-tenant routing become trivial to add.

Roadmap

Three sequential sprints, each shippable on its own:

1. Sprint E.1 — Auth domain (3–5 days): migrate login / reset password / change password. Land the filter-chain skeleton, the authorization filter, the global error filter.
2. Sprint E.2 — View core (7–10 days): migrate view / data / form / save / save-cache / enter-edit / form-close / delete. Implement the new [TKXFormBody] attribute for binding HTTP form bodies to TKRecord instances.
3. Sprint E.3 — View ancillary + extension API (5–7 days): migrate lookup / blob / tool / detail. Implement RegisterOverride. Eliminate the residual if/else from DoHandleRequest.

Total effort estimate: 2–4 weeks of focused work. No end-user behavioral change — same URLs, same payloads, same flow. Purely an architectural unblocker.

Server-Push Notifications & Background Jobs

A new framework capability to push events from the server to the browser without polling, plus a first-class background job runner for long-running operations.

The problem today

Kitto^x is currently strictly request-response. Three operational pain points:

1. Long operations block Indy threads — a 50k-row Excel export occupies one of the 20 default workers for several seconds; a few concurrent users can saturate the pool.
2. No progress feedback — the user only sees the browser spinner, with no way to know whether the system is working, stuck, or has failed.
3. No push channel — record changes by another user, completed jobs, system messages don't reach the client without per-feature polling.

The plan

Three new components designed to fit naturally with TKWebSession:

• TKXEventBus — an in-process publish/subscribe bus. Topics are scoped (user:<name>, system, job:<id>, view:<name>); subscribers are sessions. Events are typed records with Kind, Severity, Title, Body, Action, structured Payload.
• TKXJobQueue — a thread pool separate from Indy workers, sized independently (default 4). Jobs are descendants of TKXJob with virtual Execute(AContext); the context offers ReportProgress, EmitEvent, IsCancelled, ArtifactPath. Job submission returns a JobId; the HTTP request returns immediately with 202 Accepted.
• TKXSSEHandler — a long-lived endpoint at /app/kx/events over Server-Sent Events. One per session, kept alive with a 15s comment heartbeat; the HTMX SSE extension handles client reconnection automatically.

What developers get

A simple submission API:

LParams := TJSONObject.Create;
LParams.AddPair('viewName', ViewTable.View.PersistentName);
LJobId := JobQueue.Submit(TKXExportXlsxJob, LParams, Session.AuthData.UserName);

Response.StatusCode := 202;
Response.ContentType := 'application/json';
Response.Content := Format('{"jobId":"%s"}', [GUIDToString(LJobId)]);

What end users get

• Toast notifications for transient events (severity-driven duration)
• Notification center in the topbar (bell icon with unread badge)
• Inline progress bars for jobs the user has launched
• Persistent notification log (optional, in KX_NOTIFICATIONS table) so notifications survive logout/login

Out of scope for v1

• Multi-instance pub/sub (Redis / NATS) — single-instance + sticky-session assumed in v1
• DB-driven events (PostgreSQL LISTEN/NOTIFY, Firebird events, SQL Server Service Broker) — too costly to abstract across three engines for v1; only app-driven events from Delphi code
• SSE under ISAPI / Apache — TWebRequest / TWebResponse don't stream cleanly; v1 SSE is standalone-Indy only

In-App Help Chat

A chat panel for operational help to end users of a Kitto^x application — not a developer tool. The audience is the person using the deployed app ("how do I export this list?", "why can't I save this record?"), with the goal of reducing support load and improving onboarding.

Scope of v1

The plan is to ship the infrastructure first, with stub providers, so that integrating an AI backend later is a one-liner. The deliverable is:

• A new Source/Kitto.Html.Chat.pas controller (TKXChatController extending TKXComponent)
• A floating drawer panel reachable from a topbar button — slide-in, ~400px wide, full height
• Persistence on two new tables (KX_CHAT_CONVERSATION, KX_CHAT_MESSAGE) with a CONTEXT JSON column for view/record contextualization
• A pluggable provider interface IKXChatProvider with three v1 stubs: Echo (testing), Static FAQ (keyword match → YAML-defined replies), System (slash commands like /clear, /help, /whoami)
• Streaming responses over the same SSE transport from the Notifications system above (no second connection)

Future providers

The interface is designed so AI backends slot in without UI changes:

Provider	Notes
TKXClaudeProvider	Native streaming via https://api.anthropic.com/v1/messages
TKXOpenAIProvider	OpenAI Chat Completions
TKXLocalLLMProvider	OpenAI-compatible local endpoints (Ollama, LM Studio)
TKXRAGProvider	Retrieval-augmented from this VitePress documentation as the corpus

Privacy and safety

Configuration knobs planned from day one: per-user conversations (no cross-user reads), opt-out of context fields (e.g. don't send PII to a cloud provider), audit log of provider calls (metadata only — timestamp, user, tokens, cost — never message bodies), per-user rate limiting.

This feature has no relationship to the MCP server below. The chat is end-user help inside a deployed application; the MCP server is a developer tool. Different audiences, different infrastructure, different licensing.

MCP Server for AI-Driven Development

Now in progress — base shipped

This initiative has moved from "planned" to "in active development". The first 8 tools (Phases 1+2 — meta_* and project_* including project_create_app) are already implemented and shipping with KIDE^x. See What's New — MCP-KittoX for the high-level summary, or the dedicated MCP-KittoX page for the live feature matrix and setup instructions.

The remaining roadmap (Phase 3+) covers reverse-engineered Models from a database (models_create_from_db), Views/Layouts/MainMenu generation, validators, locale .po updates, DB introspection — see the Planned tools table for the full list with current status.

How These Features Relate

The three new features are largely orthogonal but share infrastructure where it makes sense:

• Notifications and Help Chat share the SSE transport (/app/kx/events). The chat panel does not open a second connection — token-streamed responses are events on the existing channel.
• MCP-KittoX (now in progress with shipped base) is fully separate: different audience (developer / agent), different process (standalone), different licensing (Enterprise only). It does not share code with the in-app chat. The only optional touchpoint with Notifications is later in the MCP roadmap: the server can publish on the runtime app's event bus to invalidate metadata cache after agent-driven edits.

The routing refactor is the foundation underneath all of them: once it lands, the new feature endpoints (/app/kx/events, /app/kx/chat/*) plug into the attribute registry instead of expanding the legacy if/else, and the filter chain provides a clean place for cross-cutting policies (authorization, audit, rate limiting).

See Also

• What's New in 4.0 — features already shipped in the 4.0 line
• Release Notes — detailed version history
• Attribute-Based Routing — the foundation the routing refactor builds on
• JWT Authenticator — the authentication layer that will become a filter
• KIDEX — the visual IDE that the MCP server will mirror for AI agents

Feedback welcome

If any of these directions matter to your project — or if you'd like to see a different priority — let us know via the GitHub issues or drop a line at info@ethea.it.