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 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	Shipped — see Attribute-Based Routing, Request Flow, Release Notes
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

Shipped

This architectural refactor is complete. Every URL endpoint is now attribute-routed under a shared request-filter chain; the legacy TKWebApplication.DoHandleRequest if/else dispatch has been removed and now serves only the application root /. Application code can replace or extend any endpoint by subclassing the framework handler and calling TKXResourceRegistry.RegisterOverride — no fork required.

See Attribute-Based Routing (including the RegisterOverride and filter sections), Routing and Request Flow, and the Release Notes entry for the details. The section below is kept as a summary of what the refactor delivered.

The routing layer is unified under the attribute-based model already used by the Enterprise data handlers (ChartPanel, CalendarPanel, GoogleMap). Two core handlers cover the whole surface: TKXAuthHandlerBase (login / reset / change / logout) and TKXViewHandlerBase (the entire view domain — view / data / form / save / save-cache / delete / enter-edit / form-close / lookup / wizard-finish / master-detail / tool / upload / notify / blob).

For app developers — RegisterOverride

Customizing a framework endpoint no longer means forking. An application derives from the base handler and registers the subclass:

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

initialization
  TKXResourceRegistry.Instance.RegisterOverride(TLoginHandlerHello);

Extension points are exposed as virtual hooks: auth (BuildAuthData / AfterAuthenticateOK / AfterAuthenticateFail / ResetPasswordEmail) and view CRUD (OnBeforeSave / OnAfterSave / OnBeforeDelete / OnAfterDelete). Hook-only overrides need no re-annotation; replacing a whole endpoint re-declares that method's routing attributes.

Filter chain

Cross-cutting concerns (authorization, error handling, session-lost detection) live in a request filter chain (IKXRequestFilter with BeforeInvoke / AfterInvoke / OnException). The auth gate is a standard filter, with the [TKXAnonymous] attribute opting specific endpoints out (login, password reset). Application-side filters for audit logging, rate limiting or multi-tenant routing are trivial to add.

No end-user behavioral change — same URLs, same payloads, same flow. Purely an architectural unblocker for the features below.

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 (now shipped) is the foundation underneath all of them: 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
• KIDE^x — 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.