When starting a new application, supporting multiple languages can easily end up somewhere near the bottom of the priority list. And when localization is added later to an existing or even long-running application, suddenly there are captions, messages, dialogs and other texts scattered all over the project that all need to be found, translated and kept in sync.

From a Real-World Need to TMS FNC Localization

For readers who have been following our blog, the name Erwin Denissen might already sound familiar.

Erwin is the developer behind FontCreator from High-Logic, which we featured earlier in one of our customer showcase blog posts. As part of his own software development, Erwin also ran into the challenges that come with adding and maintaining localization in an application.

Not finding a solution that matched the workflow he was looking for, he started building his own.

What began as a solution for his own needs eventually brought Erwin and TMS Software together. We saw a lot of potential in his work, and from that cooperation the project grew further into the product we are presenting today as TMS FNC Localization.

We want to explicitly thank Erwin for the work, ideas and experience he has contributed to making this possible!

Collect, Translate, Apply!

At its core, TMS FNC Localization is built around a straightforward workflow: collect the texts, translate them and apply the selected language. Instead of having to build the complete localization infrastructure yourself, you get dedicated components for each step!

Collect

The first challenge is finding everything that needs to be translated, especially in an existing application. The TTMSFNCLocalizationCollector helps gather localizable content from your application instead of forcing you to manually hunt down every caption and text property.

//Analyze and collect the application - only applies to live forms
TMSFNCLocalizationCollector.AnalyzeApplication;
//Analyze and collect a given form
TMSFNCLocalizationCollector.AnalyzeForm(Self);

Translate

Once the strings have been collected, they need to be managed and translated.

The TTMSFNCLocalizationEditor provides an easy way to work with the collected texts and the translations for the different languages. Opening the editor at runtime comes with the benefit of being able to see the translation changes immediately in your running application.

TMSFNCLocalizationEditor.Execute;

Alternatively, open it at design time from the context menu of the TTMSFNCLocalizationCollector or any TForm. When the editor is triggered at design time, you can also see which forms haven't been discovered yet!

What if you don't want to manually translate every item? Use the optional AI assistance to generate translations and you'll only need to verify the results! We've added support for a variety of AI services that you can use with your API key. These include OpenAI, Claude, Gemini, Grok, Mistral and DeepSeek. If you prefer local models, we have you covered via Ollama and llama.cpp.

Would you rather leave it to a professional? XLIFF export and import support is available, allowing you to outsource the work to professional translators using their own tools!

To help keep translations reliable, TMS FNC Localization comes with built-in automatic text validation for format specifiers, placeholders, accelerator keys, line breaks and whitespace, whether translations are entered manually, imported or generated with AI. It supports plural-aware translations as well, allowing the correct wording to be used depending on the quantity being displayed. This is especially useful for languages where pluralization rules go beyond a simple singular-versus-plural distinction.

On top of editing and verifying the translations, the TTMSFNCLocalizationEditor also lets you manage the list of languages you want to support, along with a set of exclusion rules for what should not be collected. Using the editor also means collection happens automatically, no need for additional code!

The editor keeps the translation process separate from the application itself. Adding another language or updating an existing translation becomes a matter of maintaining the localization data instead of changing forms or source code.

Apply

Finally, the TTMSFNCLocalizationLocalizer takes care of applying the selected language to the application! Point it to the folder where the localization files live, and calling the simple TrySetLocale method will immediately switch to the target language. This gives you fine control over when and how a language is set. If you'd rather hand that choice to your users, TMS FNC Localization ships with a ready-made language picker, TTMSFNCLocalizationCombobox, that you can drop straight into your forms!

Together, these components turn localization into a repeatable workflow instead of a one-off solution. When another language needs to be added later, you can simply repeat the same step again!

New or Existing, Localization Fits

Of course, the easiest moment to think about localization is before writing the first line of an application. From the start, you can keep your strings in one place with TTMSFNCLocalizationStringCatalog. That way you can keep everything organized, central and easy to collect.

That said, one of the goals behind TMS FNC Localization is to make localization approachable not only for new projects, but also for applications that already exist. Localization no longer has to be an all-or-nothing decision made on day one. You can introduce it gradually and grow it as the application grows.

Get Started with the BETA

TMS ALL-ACCESS users can start experimenting with TMS FNC Localization today! The BETA is available through TMS Smart Setup, making it easy to add the product to your development environment and keep up with new BETA versions as they become available.

To help you get started, we have included demos with the installation and prepared documentation covering both the component API and the overall workflow. Click here to open it on our new TMS Documentation site, the new home for all TMS product documentation.

Help Us Shape TMS FNC Localization

Localization requirements can differ significantly between applications, and feedback from developers using the product on real projects is extremely valuable.

If you are an ALL-ACCESS user, we encourage you to put it to work! Try it on a new application or, even better, try it on that older project that someone has just decided needs to conquer three new markets. Let us know what works well, what could work better and what is missing from your localization workflow!

Feedback and findings can be shared with us through the dedicated TMS Support Center category. We are looking forward to seeing what you build with it and in how many languages!

TMS FNC UI Pack 7.3

TMS FNC Data Grid 2.0

Intro

A grid can contain every answer and still make the important ones hard to find. Which sales representatives are leading the quarter? Which targets are at risk? Where is growth slowing down? Traditionally, answering those questions visually meant writing custom drawing events and maintaining the same business logic in several places.

With TMS FNC UI Pack 7.3, we are releasing TMS FNC Data Grid 2.0 and introducing a new declarative conditional-formatting engine for TTMSFNCDataGrid.

Conditional formatting lets the data decide how a cell or row should look. Add rules for values, text, dates, rankings, averages, duplicates or complete expressions, and the grid automatically applies fills, font styles, color scales, data bars and icon sets while it renders.

From Raw Values to Instant Insight

The new ConditionalFormatting property owns a collection of rules. Each rule defines three things:

• where it applies;

• when it matches;

• how the matching cell or row should be presented.

Rules are evaluated automatically as the grid paints, and remain effective when users scroll, sort or filter. There is no need to repeat the same decisions in OnGetCellLayout or a custom drawing event.

The engine includes ten rule families:

• cell-value comparisons;

• text matching;

• date conditions;

• top and bottom rankings;

• above- and below-average rules;

• unique and duplicate values;

• two- and three-color scales;

• data bars;

• icon sets;

• custom expressions.

Start with One Line

The convenience methods make common formatting rules deliberately small. To highlight every value below 100 in the Quota % column:

with TMSFNCDataGrid1.ConditionalFormatting.AddCellValueRule(
  COL_QUOTA, gfcLess, '100') do
  Appearance.Font.Color := gcRed;

ConditionalFormatting.Enabled is enabled by default, so the rule takes effect immediately.

Color Scales: See the Range

A color scale turns a numeric column into a compact heat map. The lowest, middle and highest values receive the selected colors, with the colors in between calculated automatically.

TMSFNCDataGrid1.ConditionalFormatting.AddColorScale(
  COL_SALES,
  gcRed,
  gcYellow,
  gcLimegreen);

This is useful for sales, margins, temperatures, scores or any other measurement where relative position matters as much as the number itself.

Data Bars and Icon Sets: Compare at a Glance

Data bars show magnitude directly inside a cell while keeping the original value visible. Icon sets divide values into recognizable bands using arrows, traffic lights, stars, flags and rating symbols.

// Compare quota attainment with proportional bars.
TMSFNCDataGrid1.ConditionalFormatting.AddDataBar(
  COL_QUOTA, gcDodgerblue);

// Show the direction of growth with traffic lights.
TMSFNCDataGrid1.ConditionalFormatting.AddIconSet(
  COL_GROWTH, gisTrafficLights3);

// Turn customer satisfaction into a five-star signal.
TMSFNCDataGrid1.ConditionalFormatting.AddIconSet(
  COL_CSAT, gisStars5);

The minimum and maximum values can be detected automatically or defined as numbers, percentages or percentiles. Values can remain visible next to the bar or icon, or the visual can stand on its own.

Highlight the Rows That Matter

Some conditions should draw attention to a complete record. ApplyToEntireRow extends the appearance of a matching rule across the row while the condition itself remains tied to one column.

with TMSFNCDataGrid1.ConditionalFormatting.AddTopBottomRule(
  COL_SALES, rkTop, 5) do
begin
  Priority := 10;
  ApplyToEntireRow := True;
  Appearance.Fill.Color := gcLightgoldenrodyellow;
  Appearance.Font.Style := [TFontStyle.fsBold];
end;

This example highlights the five best sales results without calculating or updating a threshold manually.

Expressions Across Columns

For decisions that depend on more than one value, expression rules use the same expression language as the Data Grid filter builder. Column names can be combined into a readable condition that is evaluated for each row.

with TMSFNCDataGrid1.ConditionalFormatting.AddExpressionRule(
  '([Growth %] < 0) AND ([Quota %] >= 100)') do
begin
  ApplyToEntireRow := True;
  Appearance.Fill.Color := gcMistyrose;
  Appearance.Font.Color := gcRed;
end;

This makes it easy to reveal combinations that deserve attention: growth declining despite reaching quota, stock falling below the reorder level, an overdue task that is still open, or a customer whose health indicators disagree.

Combining Rules with Priority

Conditional formatting becomes especially useful when several rules work together. A sales column can use a color scale, a quota column can show data bars, growth can display an icon set, and status can apply text-based colors—all in the same grid.

When rules overlap, a lower Priority number has higher precedence. The first matching rule claims the appearance aspects it sets, while later rules can still contribute aspects that remain unset. StopIfTrue can stop evaluation of the rules that follow it.

This gives you predictable layering without moving presentation logic into paint handlers.

A Visual Editor for VCL and FireMonkey

Not every formatting rule needs to start in code. TMS FNC Data Grid 2.0 includes a visual conditional-formatting editor for VCL and FireMonkey at design time.

The editor lets you:

• add, duplicate, delete and reorder rules;

• choose a rule type and its scope;

• select columns by name;

• configure comparisons, values and expressions;

• select fills, text colors, borders and font styles;

• configure color-scale bounds, data bars and icon sets;

• preview the selected rule before accepting it.

The rule collection is stored with the grid, so design-time configuration becomes part of the form just like the grid's other properties. Desktop applications can also open the same workflow at runtime with ShowConditionalFormattingEditor.

Cross-Framework by Design

The conditional-formatting engine is available in TTMSFNCDataGrid for VCL, FireMonkey and TMS WEB Core. The visual editor is available for VCL and FireMonkey, while the same rule collection and fluent helper methods can be configured in code on all three frameworks.

That means the formatting logic can travel with your application instead of being rewritten for each UI framework.

Installing TMS FNC UI Pack 7.3

TMS FNC UI Pack 7.3 is available through the modern Smart Setup based installation workflow:

tms self-update
tms install tms.fnc.*

If you are moving from the classic installers, uninstall older TMS FNC UI Pack installations from the previous setup flow first. This keeps IDE paths and package registrations clean.

You can learn more about TMS FNC UI Pack on the product page.

Conclusion

Conditional formatting in TMS FNC Data Grid 2.0 turns visual data analysis into a reusable part of the grid configuration. From one-line threshold rules to color scales, rankings, icon sets and expressions across multiple columns, the new engine makes important values stand out without custom painting code.

Together with the visual editor and the fluent runtime API, TMS FNC UI Pack 7.3 gives developers a faster way to build grids that do more than display data—they explain it.

Throughout this series, we've looked at different ways of building and applying filters.

We started with the TTMSFNCFilterBuilder, moved on to visual filter dialogs, and then used TTMSFNCFilterView to let users build filters naturally through controls in the application.

Until now, the result of a filter was mainly used to answer one question:

Does this item match the filter?

With the new TTMSFNCFilterRulesManager, we can take that answer and do something with it.

Instead of only filtering data, a matching expression can now change a property, show or hide controls, enable or disable functionality, or execute your own application logic.

From Filters to Rules

The easiest way to understand the Filter Rules Manager is to look at a rule as three parts:

• Where? - Which objects should be evaluated?
• When? - Which filter condition should match?
• What? - What should happen when it matches?

For example:

For all employees
where Country = 'Belgium'
set Visible = True

Or:

For all controls
where Name starts with 'btn'
set Visible = False

The filter itself is still handled by the same filtering logic we've introduced throughout this series.

The difference is that we now attach one or more actions to the result.

A First Rule

Let's start with a small example.

Suppose we have a panel containing several controls and only want controls whose name starts with btn to be visible.

With the Filter Rules Manager, this can be expressed in one rule:

mgr.AddRuleStartsWith(
  'ShowActionButtons',
  pnlControls,
  'Controls[*]',
  'Name',
  'btn',
  False
).AddVisibilityAction;

There is quite a lot happening in only a few lines, so let's break it down.

The Source

Every rule starts with a Source.

The source is the object from which the Filter Rules Manager starts looking for the items it should process.

In our example, that is:

pnlControls

But the source itself does not necessarily have to be the object we want to change.

Instead, we can navigate from the source to other objects in the source using an ItemsPath.

The ItemsPath

For our panel example, the ItemsPath is:

Controls[*]

This tells the Filter Rules Manager to process all controls belonging to the panel.

The * indicates that every item in the collection should be evaluated.

So our rule now effectively says:

For every control inside pnlControls...

If the ItemsPath is left empty, the rule can also be applied directly to the Source itself.

This makes rules useful for both individual objects and collections of objects.

The Filter

Next, we need to decide when the rule matches.

In our example, we evaluate the Name property:

Name starts with 'btn'

Internally, the rule uses TTMSFNCFilterBuilder to evaluate this expression.

This is important because it means the Filter Rules Manager isn't introducing another expression language.

The same operators and structured filtering concepts from the earlier parts of this series are reused here.

You can create a rule using one of the helper methods, as we did above, or provide filter text directly.

Rule.FilterText := 'Name LIKE ''btn%''';

More complex expressions can also be used, including combinations of multiple conditions.

The Action

So far, we know which objects we are processing and which ones match.

Now comes the new part: what should happen?

In our example, we added:

AddVisibilityAction

This changes the Visible property depending on whether the item matches the filter.

A matching control becomes visible, while a non-matching control becomes hidden.

The complete rule can therefore be read almost as a sentence:

mgr.AddRuleStartsWith(
  'ShowActionButtons',
  pnlControls,
  'Controls[*]',
  'Name',
  'btn',
  False
).AddVisibilityAction;

For all controls on this panel, find the controls whose Name starts with "btn", and set their visibility accordingly.

Actions Are Not Limited to Visibility

AddVisibilityAction is a convenient shortcut, but actions are not limited to the Visible property.

An action can target another property using an RTTI path.

Conceptually, an action consists of:

• A target property
• A value when the filter matches
• Optionally, a value when it doesn't match
• Optionally, a value when the rule is inactive

For example:

Rule.AddAction(
  'Enabled',
  True,
  False
);

A matching item will have Enabled set to True, while a non-matching item will have it set to False.

There are also convenience methods for common scenarios:

Rule.AddVisibilityAction;
Rule.AddEnableAction;
Rule.AddDisableAction;

And because the target is a property path, actions can go beyond simple top-level properties.

This opens the door to changing appearance and other properties based on filter conditions as well.

Multiple Actions on One Rule

A rule isn't limited to one action either.

Once an item matches, multiple properties can be changed as part of the same rule.

For example, a rule could make an item visible and enable it at the same time:

Rule
  .AddVisibilityAction
  .AddEnableAction;

This keeps the condition in one place.

You don't need to evaluate the same expression several times just because multiple things should happen when it matches.

Rules Can Be Active or Inactive

Every rule has an Active property.

This gives you an easy way to switch behavior on or off.

mgr.Rules[0].Active := not mgr.Rules[0].Active;
mgr.Rules[0].Apply;

When a rule is active, its filter is evaluated and the match or no-match actions are applied.

When it is inactive, the rule can use an InactiveValue instead.

This is useful when disabling a rule should also restore the objects to a known state.

So an action can effectively have three outcomes:

• Match - the item matches the filter.
• No match - the item doesn't match.
• Inactive - the rule itself is disabled.

Rules on Your Own Objects

The Filter Rules Manager is not limited to visual FNC controls.

One of the more interesting use cases is applying rules to your own Delphi objects.

Suppose we have an employee object:

TEmployee = class(TComponent)
private
  FName: string;
  FCompany: string;
  FCity: string;
  FCountry: string;
  FVisible: Boolean;
published
  property Name: string read FName write FName;
  property Company: string read FCompany write FCompany;
  property City: string read FCity write FCity;
  property Country: string read FCountry write FCountry;
  property Visible: Boolean read FVisible write FVisible;
end;

We can then create a rule that evaluates these objects and writes the result directly to their Visible property.

FManager
  .AddRuleStartsWith(
    'NameFilter',
    FEmployees,
    'Items[0..*]',
    'Name',
    'A'
  )
  .AddVisibilityAction;

When the rule is applied, the manager iterates over the employees, evaluates the Name property and updates Visible.

Your application can then decide how that property is used.

A grid could display only visible employees, for example, without the Filter Rules Manager needing to know anything about that grid.

Dynamic Rules with Placeholders

So far, the values in our rules have been fixed.

But application rules are often based on values that change at runtime.

This is where placeholders become useful.

A placeholder connects part of a rule to a property on another object.

For example, suppose we have a search edit:

FManager.AddPlaceholder(
  'SearchText',
  EditSearch,
  'Text'
);

We can then use that value inside the rule:

{SearchText}

Every time the rule is applied, the current value of EditSearch.Text is used.

This means the rule doesn't have to be recreated whenever the search text changes.

Even the Field Can Be Dynamic

Placeholders are not limited to filter values.

They can also be used in other parts of the rule, including the field being filtered.

For example, imagine a ComboBox where the user selects whether to search by Name, Company, City or Country.

We can first retrieve the selected index:

FManager.AddPlaceholder(
  'SearchFieldComboIndex',
  SearchFieldCombo,
  'ItemIndex'
);

Then use that index to retrieve the selected field:

FManager.AddPlaceholder(
  'FilterField',
  SearchFieldCombo,
  'Items[{SearchFieldComboIndex}]'
);

And finally use both placeholders in the rule:

FManager
  .AddRuleStartsWith(
    'EmployeeFilter',
    FEmployees,
    'Items[0..*]',
    '{FilterField}',
    '{SearchText}'
  )
  .AddVisibilityAction;

The same rule can now search different properties without being rebuilt.

Change the ComboBox, enter another search value, call Apply, and the current values are resolved automatically.

Applying the Rules

Once the rules have been configured, they can be applied through the manager:

FManager.Apply;

The manager processes its rules and, for each rule:

• Resolves the source and item path.
• Resolves any placeholders.
• Builds the filter.
• Evaluates the filter against every item.
• Determines whether the item matches.
• Applies the corresponding actions.

A rule can also be applied individually:

FManager.Rules[0].Apply;

This is useful when only one particular rule needs to be refreshed.

What If an Action Is Not a Property?

Not every action can be expressed as setting a property.

Sometimes you need to execute application-specific code.

For those situations, rules also support callbacks.

The callback receives the rule, the current item, its index and whether it matched.

This gives you the structured rule evaluation while leaving the final behavior completely up to your application.

There are also manager events available when you need more control over whether a rule or item should be processed, or when you want to override the resulting match.

For most common cases, however, property actions keep the implementation much simpler and avoid unnecessary event handlers.

Counting Matches Without Applying Actions

Sometimes you only want to know how many items currently match a rule.

For that, a rule provides CountMatchingItems.

Count := Rule.CountMatchingItems;

This evaluates the filter without writing the action values to the objects.

It can be useful for previews, counters or showing the user how many items a rule will affect before applying it.

Why a Filter Rules Manager?

Of course, all of this could also be written manually.

You could iterate over a collection, write several if statements, change properties and repeat that logic whenever the application state changes.

But as the number of conditions grows, that logic quickly becomes spread throughout the application.

The Filter Rules Manager brings those pieces together:

• The condition is represented by a filter.
• The objects to evaluate are defined by a source and item path.
• The result is connected to one or more actions.
• Runtime values can be supplied through placeholders.
• The complete rule can be enabled, disabled and reapplied.

Instead of writing:

if Employee.Country = 'Belgium' then
begin
  Employee.Visible := True;
  Employee.Enabled := True;
end
else
begin
  Employee.Visible := False;
  Employee.Enabled := False;
end;

The condition and its effects become a reusable rule.

Where Can This Be Used?

The Filter Rules Manager isn't specifically a grid filtering component or a UI visibility component.

It is deliberately more generic.

Some examples include:

• Show or hide controls depending on application state.
• Enable actions only when certain conditions are met.
• Change the appearance of matching items.
• Apply rules to collections of your own objects.
• Highlight records requiring attention.
• Control which application actions are currently available.
• Apply multiple property changes from a single condition.

And because the logic is based on the same filtering foundation used throughout this series, you don't need to learn another way of describing conditions.

From Filtering Data to Application Logic

This is ultimately the idea behind TTMSFNCFilterRulesManager.

A filter doesn't necessarily have to mean:

"Remove everything that doesn't match."

It can simply describe a condition:

"When this matches, do this."

By separating the condition from the action, the same structured filtering logic can be used in many more places throughout an application.

And because rules can work with component properties as well as your own objects, the Filter Rules Manager isn't tied to one particular control or use case.

It takes the FilterBuilder we've been using throughout this series and turns it into a more general rules system for Delphi applications.

Model Context Protocol (MCP) is the standard that lets AI clients like Claude Desktop, ChatGPT, Cursor, ... call out to your own tools. An MCP server exposes a set of functions, the assistant reads their descriptions, decides when to call them, and feeds the results back into the conversation.

As long as that server only talks to itself on your own machine, it doesn't need to ask "who's calling?" The moment it becomes a real server instead — reachable over the network, used by a colleague, or connected to from Claude Desktop on someone else's computer — that question matters a lot.

You've actually already answered that question dozens of times, just not for MCP. Every time you click "Continue with Google" or "Sign in with Microsoft" on some website, a login screen pops up, you approve it, and you're dropped back into the app, now connected. That familiar dance is called OAuth, and it's exactly the mechanism MCP uses to let an AI assistant connect to your server safely.

In this post we build that mechanism in Delphi. No prior knowledge of OAuth required — we'll explain each piece in plain terms as we go, then show the real, compiling Delphi code behind it.

• It's the same well-known approach used by "Sign in with Google" and every other app you've connected an account to — not something custom or proprietary.
• Turning it on for an existing MCP server is a one-line switch, not a rewrite.
• It's been tested against real AI assistants — MCP Inspector, Claude Desktop and ChatGPT have all connected through this exact code.

The two servers involved

There are two separate pieces at play here, and keeping them separate is the whole point.

One is your actual MCP server — the one with the tools the AI wants to call. The other is a small login and permissions service, whose only job is to check who someone is and hand out a token proving it. Your MCP server never checks logins itself; it just asks the login service, every time, "is this token still good, and what's it allowed to do?"

Two separate services; your MCP server trusts nothing it hasn't just double-checked with the login service.

Turning it on

If you already have an MCP server built with the TMS MCP SDK, requiring a login is not a rewrite. It's a handful of lines on the transport you already created.

Transport := TTMSMCPStreamableHTTPTransport.Create(nil, 8934, '/mcp');
Transport.RequireBearerAuthentication := True;
Transport.AuthorizationServers.Add(AuthorizationServerIssuer);
Transport.ResourceScopesSupported.Add('demo:read');
Transport.ResourceScopesSupported.Add('demo:write');
Transport.RequiredScopes.Add('demo:read');
Transport.OnValidateAccessToken := Handlers.ValidateAccessToken;

Server.Transport := Transport;

RequireBearerAuthentication := True is the actual switch: every request now needs a valid token attached, or it's refused. AuthorizationServers tells your server which login service to trust, and ResourceScopesSupported lists the permissions that exist (here, "read" and "write" access to a notes list) — both get automatically announced to any AI client that asks, so nothing needs to be configured by hand on the client side.

The one piece the SDK deliberately leaves to you is OnValidateAccessToken: the actual check of "is this token real, and what does it allow?" Different login services hand out tokens in different formats, so that decision is yours, not the transport's.

Checking a token: always ask, never assume

Here is the demo's real implementation of that check. It calls the login service and asks it directly, rather than trying to verify the token by itself.

procedure TDemoAuthHandlers.ValidateAccessToken(Sender: TObject; const AToken, AResourceURI: string;
  var AValidation: TTMSMCPAccessTokenValidation);
var
  Http: TIdHTTP;
  ReqBody, RespBody: TStringStream;
  Json: TJSONObject;
  Audience: string;
begin
  AValidation.Valid := False;

  Http := TIdHTTP.Create(nil);
  ReqBody := TStringStream.Create('token=' + TTMSMCPUtils.URLEncode(AToken));
  RespBody := TStringStream.Create;
  try
    Http.Request.ContentType := 'application/x-www-form-urlencoded';
    Http.Post(AuthorizationServerIssuer + '/introspect', ReqBody, RespBody);

    Json := TJSONObject.ParseJSONValue(RespBody.DataString) as TJSONObject;
    if not Assigned(Json) or not Assigned(Json.GetValue('active')) or
      not (Json.GetValue('active') as TJSONBool).AsBoolean then
      Exit; // not valid - AValidation.Valid stays False

    // Make sure this token was actually meant for THIS server, not some
    // other one the same login service happens to protect.
    Audience := '';
    if Assigned(Json.GetValue('aud')) then
      Audience := Json.GetValue('aud').Value;
    if Audience <> AResourceURI then
      Exit; // valid token, but issued for a different server - reject anyway

    AValidation.Valid := True;
    AValidation.Subject := Json.GetValue('sub').Value;
    AValidation.Scopes := Json.GetValue('scope').Value.Split([' ']);
  finally
    RespBody.Free; ReqBody.Free; Http.Free;
  end;
end;

That middle check — confirming the token was actually meant for this server — matters more than it looks. Without it, a token handed out for some other server (that happens to share the same login service) would be accepted here too, just because it was technically "still valid". Checking who a token was meant for is what stops it from being reused somewhere it was never supposed to work.

Put together, every single request runs through the same short checklist before a tool ever gets called:

Every call is double-checked with the login service before a tool ever runs.

What it looks like in Claude Desktop

All of the above is what makes this work under the hood. Here's what it actually looks like from the other side, adding this server to Claude Desktop as a custom connector — and it will look familiar, because it's the same "sign in and approve" pattern as any other app.

Add the connector's address and hit Connect. Approve on the sign-in screen that opens, and the connector shows connected:

Before — not yet connected

After — approved and connected

In between sits the sign-in screen itself — plain HTML, served straight from the Delphi backend, no client-side JavaScript involved:

The sign-in screen: plain server-rendered HTML, nothing exotic needed to make this part work.

The permissions you approve here decide what a token is allowed to do. Claude adds its own, separate layer of consent on top of that, per tool, before it will actually use anything:

Claude's own tool-permission setting, independent of what you approved during sign-in.

Two separate checks, worth keeping apart: the sign-in step decides what a token is entitled to at all; Claude's own permission setting decides whether it will actually use a given tool right now without asking first. Approving "write" access during sign-in doesn't mean Claude will silently add a note — that second decision stays entirely with Claude, on your machine.

From demo to a real deployment

Both servers ship two ways: as plain console apps you can run and read top to bottom in an afternoon, and as installable Windows services (a proper install command, a config file, a log file to check) for when you actually want one sitting on a server.

We ran that exact path start to finish: built as Windows services, put behind IIS on a real domain with a real certificate, and connected end to end by MCP Inspector, Claude Desktop and ChatGPT — sign in, approve, and a live tool call, all the way through.

That last stretch — going from "it works on my own machine" to "it works on a real server, for anyone" — has its own sharp edges: what address the server needs to tell clients about once it's behind a proxy, a place where the sign-in step can get silently misdirected by proxy configuration, and a couple of real bugs we found and fixed along the way. We wrote all of that down separately, in detail, rather than compress it into a footnote here: see the documentation for the full setup-to-production walkthrough.

Why this matters

• Requiring a login is a one-line switch on the server you already have, not a rewrite of your tools.
• AI clients need no manual setup to connect — the whole sign-in process is standard and already understood by MCP-aware clients, the same way "Sign in with Google" already works everywhere without you configuring anything.
• Your MCP server trusts nothing by default; every token is checked with the login service, every time, and checked against being reused on the wrong server.
• The demo login service is built to be strict by default — it won't redirect anywhere it hasn't been explicitly told is safe.
• The same code that runs as a five-minute local demo is the code we actually deployed on a real server with a real domain — this isn't a toy that stops working the moment it leaves your own machine.

Get the demo

All four projects — the two console demos and their Windows-service counterparts — are in the distribution folder under Demos/OAuth Authorization Server Demo, Demos/OAuth Resource Server Demo, Demos/OAuth Authorization Server Service and Demos/OAuth Resource Server Service.

For everything past "it runs on my machine" — turning these into installable services, adding a certificate, and putting them behind IIS on a real domain, caveats included — the documentation walks through that in the order you'd actually run into each decision.

Clone it, point a client at it, and watch the whole sign-in happen without writing a single line of client-side authentication code.

TMS AI Studio is the complete toolkit for bringing AI and the Model Context Protocol to your Delphi applications. Build MCP servers and clients, connect Claude and other assistants to your own tools and data, and add cloud AI to your VCL and FMX apps — all in native Delphi. Discover TMS AI Studio.

Exporting a GPX file through the device share sheet

procedure TCityGuide.BtnShareClick(Sender: TObject);
var
  LFileName: string;
  FName: string;
begin
  if UILogic.City <> '' then
    FName := UILogic.City + '.gpx'
  else
    FName := 'mycitytour.gpx';

  LFileName := TPath.Combine(
    TPath.GetTempPath,
    TPath.GetFileName(FName)
  );

  UILogic.ExportToGPX(TMSFNCMaps, LFileName);

  ShareFile(LFileName, 'application/xml', FName);
end;

LIntent := TJIntent.Create;
LIntent.setAction(TJIntent.JavaClass.ACTION_SEND);
LIntent.setType(StringToJString(AMimeType));

LIntent.putExtra(
  TJIntent.JavaClass.EXTRA_STREAM,
  TJParcelable.Wrap((LUri as ILocalObject).GetObjectID)
);

LIntent.addFlags(
  TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION
);

TAndroidHelper.Activity.startActivity(
  TJIntent.JavaClass.createChooser(
    LIntent,
    StrToJCharSequence(ATitle)
  )
);

LURL := TNSURL.Wrap(
  TNSURL.OCClass.fileURLWithPath(
    StrToNSStr(AFilePath)
  )
);

LItems := TNSMutableArray.Create;
LItems.addObject((LURL as ILocalObject).GetObjectID);

LActivity := TUIActivityViewController.Wrap(
  TUIActivityViewController.Alloc.initWithActivityItems(
    LItems,
    nil
  )
);

LRootVC.presentViewController(LActivity, True, nil);

ShareFile(
  '/path/to/citytour.gpx',
  'application/xml',
  'Share city tour'
);

Converting AI-generated descriptions into speech

procedure TUILogic.Speak(Description: string);
begin
  FCloudAIAudio.Speak(Description, 1, 'nova');
end;

FCloudAIAudio := TCloudAI.Create(Self);
FCloudAIAudio.Service := aiOpenAI;
FCloudAIAudio.OnSpeechAudio := SoundReady;

FMP3Player := TStreamMP3Player.Create;

procedure TUILogic.SoundReady(
  Sender: TObject;
  HttpStatusCode: Integer;
  HttpResult: string;
  SoundBuffer: TMemoryStream
);
begin
  FMP3Player.Play(SoundBuffer);
end;

Playing an MP3 stream with FireMonkey

1. It creates a unique filename using a GUID.
2. It writes the stream to TPath.GetCachePath.
3. It assigns that temporary file to TMediaPlayer.
4. It starts playback.
5. It destroys the media player before deleting the temporary file.

FMP3Player.Play(SoundBuffer);

procedure TStreamMP3Player.Play(AStream: TStream);
var
  LFileName: string;
  LFileStream: TFileStream;
begin
  if not Assigned(AStream) then
    raise EArgumentNilException.Create('AStream');

  ReleaseMedia;

  LFileName := CreateTempMP3FileName;

  AStream.Position := 0;
  LFileStream := TFileStream.Create(
    LFileName,
    fmCreate or fmShareDenyWrite
  );
  try
    LFileStream.CopyFrom(AStream, 0);
  finally
    LFileStream.Free;
  end;

  FTempFileName := LFileName;
  FMediaPlayer.FileName := FTempFileName;
  FMediaPlayer.CurrentTime := 0;
  FMediaPlayer.Play;
end;

Conclusion

• Isolate native platform APIs behind a common Delphi wrapper
• Use conditional compilation inside implementation units rather than throughout the UI
• Use secure sharing mechanisms such as Android FileProvider
• Use temporary and cache directories through System.IOUtils
• Handle asynchronous AI responses with events
• Adapt stream-based data to filename-based platform APIs
• Carefully manage native resources before deleting temporary files.

In the previous blog post, we introduced TTMSFNCFilterView and looked at how users can filter data by interacting with familiar controls instead of building filter expressions manually.

Checkboxes, combo boxes, sliders, date pickers and other controls all contribute to the same structured filter in the background.

Now it is time to see how this works in practice.

In this blog post, we will look at two examples:

• Using TTMSFNCFilterView together with TTMSFNCDataGrid.
• Extending the Filter View with your own controls.

TTMSFNCFilterView and TTMSFNCDataGrid

The first video demonstrates how TTMSFNCFilterView can be combined with TTMSFNCDataGrid to create a modern filtering interface.

The Filter View contains the controls the user interacts with, while the DataGrid displays the resulting data.

Whenever the user changes a filter control, the underlying filter expression is updated automatically.

This means you do not have to manually combine all values into one filter string or write separate filtering logic for every control.

In the video, you will see how:

• Built-in filter controls are added to the Filter View.
• Each control is linked to a field and an operator.
• Multiple controls contribute to one filter.
• The generated filter is applied to TTMSFNCDataGrid.
• Different filter actions can be used to determine how matching data is displayed.

Configuring the Filter Controls

Every control inside the Filter View has an associated filter expression.

This expression determines what should be added to the filter when the user interacts with the control.

For example, a ComboBox can be linked to a country field:

FilterComboBox.FilterExpression.FilterFieldName := 'Country';
FilterComboBox.FilterExpression.FilterFieldType := fdtText;
FilterComboBox.FilterExpression.ExpressionOperator := feoEqual;

A CheckBox can represent a Boolean value:

Active = True

And a RangeSlider can contribute both a minimum and a maximum value.

Once these expressions are configured, the controls update their part of the filter automatically.

The application only needs to determine what should happen with the resulting filter.

Applying the Filter

Because TTMSFNCFilterView uses the same FilterBuilder structure introduced earlier in this series, the resulting filter can be used in different ways.

You can:

• Apply it to TTMSFNCDataGrid.
• Assign the generated filter text to a TDataSet.
• Validate individual rows.
• Validate a complete array of data.
• Use the filter with your own controls or object collections.

The Filter View is responsible for building and maintaining the filter, while your application remains in control of how the result is applied.

Using Your Own Controls

The built-in controls cover many common filtering scenarios.

However, an application may already contain controls that should become part of the filtering interface.

You may also want to use a control that is specific to your application instead of one of the standard Filter View controls.

The second video demonstrates how your own controls can be integrated into TTMSFNCFilterView.

This allows you to create a filtering interface that matches the rest of your application without giving up the structured filtering logic.

Filter View Control Container

One way to integrate an existing control is by using TTMSFNCFilterViewControlContainer.

The Control Container acts as a bridge between the control and a filter expression.

You configure the expression that the control represents:

ControlContainer.FilterExpression.FilterFieldName := 'Status';
ControlContainer.FilterExpression.FilterFieldType := fdtText;
ControlContainer.FilterExpression.ExpressionOperator := feoEqual;

When the control value changes, you update the value stored in the expression.

ControlContainer.FilterExpression.FilterValue := 'Office';
ControlContainer.FilterExpression.AddToFilter := True;

If the control represents an option such as All, the expression can simply be excluded from the filter.

ControlContainer.FilterExpression.AddToFilter := False;

This gives you control over the user interface while the Filter View continues to manage the complete filter.

Registering Controls Programmatically

Controls can also be registered directly with the Filter View.

This is useful when controls are created dynamically or when you want to connect an existing control without placing it inside a Control Container.

For example, a calendar can be linked to a date field:

TMSFNCFilterView1.AddCustomItemControl(
  FNCCalendar,
  FNCCalendar.SelectedDate,
  'Joined',
  fdtDate,
  feoSmallerThanOrEqual
);

When the selected date changes, the linked filter value can be updated:

procedure TFilterViewForm.FNCCalendarSelectDate(
  Sender: TObject;
  ADate: TDate);
begin
  TMSFNCFilterView1.UpdateCustomItemControlValue(FNCCalendar, ADate);
end;

The custom control now participates in the same filter as all built-in controls.

One Filtering Model, Different Interfaces

The important part is that the FilterBuilder does not need to know whether an expression came from:

• A built-in Filter View control.
• A control inside a Control Container.
• A custom control registered programmatically.
• A filter dialog.
• Code written by the developer.

All of these approaches create the same structured filtering model.

This keeps the filtering logic centralized while allowing the user interface to be designed around the requirements of the application.

Why Build a Custom Filter Interface?

A predefined filter dialog is useful when users need to create detailed or occasional filters.

A Filter View is more suitable when filtering is a regular part of the application workflow.

Users can immediately see the available filter options and adjust them without leaving the current screen.

By supporting both built-in and custom controls, TTMSFNCFilterView does not force your application into one fixed layout.

• You can create a webshop-style filter panel.
• You can use toolbar buttons for status values.
• You can use a calendar for date selection.
• You can combine different controls inside filter groups.
• You can reuse controls that are already part of your interface.

The user interface can be adapted to the application, while all controls continue to contribute to one consistent filter.

Less Repetitive Filtering Code

Without a shared filtering component, every control would usually require its own event handling and filtering implementation.

The selected values would then need to be combined manually before applying the filter.

With the Filter View, each control only defines the expression it represents.

The Filter View and FilterBuilder take care of combining these expressions, adding the required groups and generating the final filter.

This reduces the amount of repetitive filtering code and makes it easier to add or change filter controls later.

What's Next?

So far, we have used filter expressions to determine which data matches and which data should be displayed.

In the next blog post, we will look at how the same filtering logic can be used to trigger other behavior.

With TTMSFNCFilterRulesManager, matching a filter can change properties, control visibility, adjust appearance or trigger application logic.

Last week we launched our free Summer Project 2026: TMS City Guide, an AI-powered virtual tour guide built entirely with Delphi.

Instead of following a predefined route, TMS City Guide creates a personalized walking tour based on your location and interests. As you walk, the app introduces you to landmarks, hidden gems and historical locations, complete with AI-generated spoken descriptions directly from your smartphone.

If you missed the original announcement, you can read all about the project in our previous blog post.

See it in action

A demo is worth a thousand screenshots, so we took TMS City Guide for a real-world test in the beautiful city of Bruges.

Watch how the app generates a walking tour on the fly, navigates between points of interest and brings each location to life with AI-generated narration.

Everything is open source

Like our previous summer projects, the complete source code is available for free. Clone it, learn from it, extend it, or use parts of it in your own applications.

The full project is available on GitHub:

Built with TMS components

TMS City Guide showcases how easy it is to combine modern AI capabilities with native cross-platform Delphi development.

The application was built using:

• TMS FNC Maps for interactive mapping and routing
• TMS FNC UI Pack for the modern user interface
• TMS AI Studio for AI integration, speech generation and intelligent content

To celebrate this summer project, we're offering a 25% discount on these products until August 31, 2026.

Simply use coupon code during checkout to activate the discount.

Coming next: Behind the scenes

The application contains several interesting Delphi techniques that deserve a closer look.

In an upcoming blog post we'll explore how we implemented:

• Exporting generated walking tours as GPX files using the native operating system Share Sheet
• Generating and streaming AI-produced speech on the fly
• Bringing together AI, mapping and native FireMonkey development into one cross-platform application

If you're interested in the technical implementation, stay tuned—we'll dive into the source code soon.

Build it. Customize it. Share it.

You can clone the project from GitHub and build it yourself for iOS or Android using Delphi. If you'd rather get started immediately, a ready-to-use Android APK is also available in the repository.

To run the application you'll need:

• an OpenAI API key
• a Google Maps API key
• Delphi

Once you've created your own walking tours, we'd love to see them! Share the cities you've explored, the routes you've generated, or the improvements you've added. Who knows—your ideas might inspire the next version of TMS City Guide.

Happy coding—and happy exploring! 🌍🚶‍♂️

Deploying a Delphi HTTP backend on Linux has always involved a decision you didn't really want to make.

You could build an Apache module with WebBroker — which means installing and configuring Apache on every server, matching module ABIs, and debugging a stack where your code is a guest in someone else's process. Or you could use the Indy-based server — self-contained, but with no built-in HTTPS (you need a third-party IOHandler), no WebSockets, and modest throughput.

Meanwhile, on Windows, Sparkle servers have had a first-class, kernel-mode HTTP server for a decade.

That gap is now closed. The next version of TMS Sparkle introduces the socket server: a complete, high-performance HTTP server written entirely in Delphi, on raw sockets. Your Linux deployment becomes a single executable that you copy to the machine and run. No Apache. No nginx. No third-party libraries to install and keep updated.

A quick refresher on TMS Sparkle

TMS Sparkle is a high-performance HTTP server framework for Delphi. It's the foundation under TMS XData (REST APIs), TMS Sphinx (OAuth 2.0 / OpenID Connect) and TMS RemoteDB (remote database access over HTTP).

Sparkle separates what your server does — modules, middleware, request handlers — from how requests reach it. That "how" is the dispatcher, and until now on Linux your dispatcher choices were Apache or Indy. The socket server is a new dispatcher, and because it implements the same module contract as all the others, existing Sparkle, XData and RemoteDB servers run on it unchanged.

Hello, world

The server class is TSocketHttpServer, in unit Sparkle.Socket.Server. If you've ever written a Sparkle server for Windows with THttpSysServer, this will look extremely familiar:

uses
  Sparkle.Socket.Server;

var
  Server: TSocketHttpServer;
begin
  Server := TSocketHttpServer.Create;
  try
    Server.AddModule(TMyServerModule.Create('http://localhost:8080/myapplication'));
    Server.Start;

    WriteLn('Server running. Press ENTER to stop.');
    ReadLn;

    Server.Stop;
  finally
    Server.Free;
  end;
end;

That's a complete HTTP server. Compile it for Linux 64-bit, copy the binary to the machine, run it — done.

Stop performs a graceful shutdown: listeners close, requests in flight are allowed to finish, and active WebSocket sessions are terminated cleanly.

A note on the host name. The socket server uses only the port of each module base URL to decide what to listen on — it always binds all interfaces (IPv4 and IPv6) — and routes requests to modules by path only. The host part is ignored, so localhost, 0.0.0.0 or your real domain name all behave the same. That matches the Http.Sys dispatcher, which by default replaces the host with the + wildcard as well (unless you set KeepHostInUrlPrefixes). In other words, the same base URL works on both dispatchers — and if you need to restrict who can reach the server, that's a job for a firewall rule or a reverse proxy.

The same applies to an XData REST API, which needs no changes at all beyond the dispatcher you host it in:

uses
  XData.Server.Module,
  Sparkle.Socket.Server;

  Server := TSocketHttpServer.Create;
  Server.AddModule(TXDataServerModule.Create(
    'http://localhost:2001/tms/xdata', ConnectionPool));
  Server.Start;

HTTPS that fits how Linux actually works

On Linux, certificates are PEM files on disk, usually renewed automatically by certbot. The socket server works exactly that way — register modules with an https URL and point the Ssl property (TSslOptions) at your files:

  Server := TSocketHttpServer.Create;
  Server.Ssl.CertificateFile := '/etc/letsencrypt/live/myapp.com/fullchain.pem';
  Server.Ssl.PrivateKeyFile := '/etc/letsencrypt/live/myapp.com/privkey.pem';
  Server.AddModule(TMyServerModule.Create('https://myapp.com:443/myapplication'));
  Server.Start;

TLS is provided by OpenSSL 3, loaded dynamically at runtime. On current distributions (Ubuntu 22.04+, Debian 12+, RHEL 9+) OpenSSL 3 is already installed, so there is nothing extra to deploy with your application. TLS 1.2 and TLS 1.3 are both supported.

Two features matter a lot in production:

Several certificates on one port (SNI). Serve multiple host names from one server, with the right certificate picked from the name the client asks for. Add TSslCertificate entries to SniCertificates; wildcards are supported:

var
  Cert: TSslCertificate;
begin
  Cert := TSslCertificate.Create;
  Cert.HostName := '*.example.com';
  Cert.CertificateFile := '/etc/myserver/example-com.pem';
  Cert.PrivateKeyFile := '/etc/myserver/example-com.key';
  Server.Ssl.SniCertificates.Add(Cert);
end;

Certificate renewal without downtime. Let's Encrypt certificates expire every 90 days. Restarting your server to pick up a renewal means dropping connections. Instead, call ReloadCertificates — the files are re-read and applied to new connections, while listeners and established connections keep running:

  // e.g. from a certbot deploy hook, or a nightly timer
  Server.ReloadCertificates;

If the new files can't be loaded, an exception is raised and the current certificates stay in use — a bad renewal can't take your server down.

WebSockets on Linux — finally

Sparkle has supported WebSockets since 2024, but only on Windows. The socket server brings them to Linux, using the exact same API and TWebSocketMiddleware, over both ws and wss:

type
  TWsEchoModule = class(THttpServerModule)
  public
    constructor Create(const ABaseUri: string); override;
    procedure ProcessRequest(const C: THttpServerContext); override;
  end;

constructor TWsEchoModule.Create(const ABaseUri: string);
begin
  inherited Create(ABaseUri);
  AddMiddleware(TWebSocketMiddleware.Create);
end;

procedure TWsEchoModule.ProcessRequest(const C: THttpServerContext);
var
  Upgrader: IWebSocketUpgrader;
  WebSocket: IWebSocket;
  Msg: IWebSocketMessage;
begin
  Upgrader := C.Item<IWebSocketUpgrader>;
  if Upgrader = nil then
  begin
    C.Response.StatusCode := 400; // not a WebSocket upgrade request
    Exit;
  end;

  WebSocket := Upgrader.Upgrade;
  repeat
    Msg := WebSocket.Receive;
    case Msg.MessageType of
      TWebSocketMessageType.Text:
        WebSocket.Send('echo: ' + Msg.Text);
      TWebSocketMessageType.Close:
        begin
          WebSocket.SendClose(WebSocketStatusCodes.NormalClosure);
          Break;
        end;
    end;
  until False;
end;

Idle WebSocket sessions are exempt from the read and keep-alive timeouts, so long-lived push connections just work.

Static files in the same binary

A REST API usually ships with something to serve: an SPA, a few images, a landing page. Use the standard TStaticModule and it all lives in one process:

uses
  Sparkle.Module.Static;

  Server.AddModule(TStaticModule.Create('http://localhost:8080/', '/var/www/myapp'));

Routing is by path, exactly as in every other Sparkle server — so your API on /tms/xdata, a WebSocket endpoint on /ws, and static files on / coexist happily on one port.

Handlers that wait — sized automatically

Here's the part that usually bites people who write their own server, and the reason a naive thread pool is not enough.

A worker thread is busy for as long as your handler runs. Handlers that return immediately need very few threads. But a handler that waits — for a database query, for an API call to another service — holds its worker while doing nothing at all. With a fixed pool, your throughput is capped at workers ÷ handler duration, no matter how idle the machine is. Sixteen threads and a 200 ms query means 80 requests per second, on a machine that's 95% idle.

The socket server sizes its pool on its own:

• It starts with WorkerThreads threads (default: twice the processor count).
• Whenever requests are waiting for a worker, it adds threads, up to MaxWorkerThreads (default: 256).
• Threads above the minimum exit after 30 seconds without work, so the pool shrinks back when the load drops.
• Requests that are handled immediately never grow the pool — a CPU-bound server keeps running on its initial threads.

In most cases the defaults are simply correct and there is nothing to configure. You set these properties when you want a different shape — most commonly to put a ceiling on threads that compete for a limited resource:

  // A database-bound API against a pool of 50 connections:
  // more workers than that would only queue up waiting for a connection.
  Server.WorkerThreads := 16;
  Server.MaxWorkerThreads := 50;

Built to face the internet

The socket server is designed to be exposed directly, without a reverse proxy in front of it, so the defensive parts are built in rather than left to nginx:

• Slowloris protection — HeaderReadTimeout bounds how long a client may take to send its request head (and the TLS handshake). Slow clients never occupy a worker thread: the event loop reads request heads, and only complete requests are handed to a worker.
• Overload protection — MaxConnections caps simultaneous connections and MaxQueuedRequests caps how many requests may wait for a free worker. Beyond that, the server answers 503 and closes, rather than accumulating unbounded latency.
• Size limits — the Limits property (TSocketServerLimits) bounds the request line, individual headers, header count, total head size and body size, with the correct status code for each violation (413, 414, 431, 400).

  Server.Limits.MaxBodySize := 50 * 1024 * 1024; // reject bodies over 50 MB
  Server.KeepAliveTimeout := 30000;

You can still put nginx or Caddy in front if you want HTTP/2, HTTP/3, rate limiting or centralized certificates — just add the forward middleware so your handlers see the original client address and scheme.

The RAD way

If you build your servers by dropping components on a data module, there's a new dispatcher component: TSparkleSocketDispatcher. Connect your TXDataServer, TSparkleStaticServer or other server components to it through their Dispatcher property, set Active to True, and you're running.

The underlying server object is available through Server for anything you need to configure from code:

uses
  Sparkle.Comp.SocketDispatcher;

  SparkleSocketDispatcher1.Server.Ssl.CertificateFile := '/etc/myserver/cert.pem';
  SparkleSocketDispatcher1.Server.Ssl.PrivateKeyFile := '/etc/myserver/key.pem';
  SparkleSocketDispatcher1.Active := True;

Deploying: a binary and a systemd unit

Deployment is about as simple as it gets. Compile for Linux 64-bit, copy the binary, and register it as a systemd service in /etc/systemd/system/myserver.service:

[Unit]
Description=My Sparkle server
After=network.target

[Service]
ExecStart=/opt/myserver/myserver
Restart=always
User=myserver
Group=myserver

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myserver

Binding to ports below 1024 needs privileges — either run as root, or grant just the one capability the binary needs:

sudo setcap cap_net_bind_service=+ep /opt/myserver/myserver

How fast is it?

Fast enough that the network is usually the interesting part, not the server.

Measured on a 4-vCPU Ubuntu 24.04 VM with wrk, 30-second runs (as always with benchmarks: your hardware, handlers and payloads will differ):

Throughput scales monotonically with concurrency — there is no dip at moderate connection counts, and no connection resets in the stress runs.

A fair-play note on that Indy column: those are tuned Indy numbers. Indy does not set TCP_NODELAY on accepted connections, so with shipping defaults Nagle's algorithm and the TCP delayed-ACK timer hold small keep-alive responses back by ~40 ms, capping each connection at roughly 24 req/s. The benchmark disables Nagle per connection so the comparison measures the servers rather than a missing socket option. The socket server sets TCP_NODELAY on every accepted socket itself, so there is nothing to remember and no such trap.

More interesting than the raw numbers is the blocking-handler behaviour, because that's what a real XData API does all day. With handlers that wait 500 ms and 256 concurrent connections, the socket server served 509 req/s — against 504 for an equivalent Node.js server and 510 for Go, on the same box in the same session. That's 99–100% of the arithmetic ceiling (concurrency ÷ latency): the elastic worker pool means a Delphi server waiting on a database is not at a disadvantage against the stacks people usually reach for.

And how stable is it?

Speed is the easy half. A server that is exposed to the internet has to survive the boring part — days of load, misbehaving clients, and load it cannot possibly serve. The socket server was built and measured with that in mind:

• It doesn't leak. Through hours of continuous benchmarking, thread count and open file descriptors tracked concurrency exactly and returned to baseline between runs, with resident memory flat at the end of the campaign.
• No errors where it counts. Every database-shaped scenario — handlers waiting 50 ms to 500 ms, at 64 and 256 concurrent connections — completed with zero errors and zero dropped connections, on both Linux and Windows.
• Predictable at the limit. When load exceeds what the configured workers can serve, it answers 503 and closes rather than queueing without bound, so an overloaded server stays responsive and recovers as soon as the spike passes. That threshold is yours to size, via MaxWorkerThreads and MaxQueuedRequests.
• Malformed and hostile input is handled by design, not by luck. The HTTP parser was fuzzed, and every limit violation maps to a defined status code rather than an unhandled exception.
• It runs the same test suite as every other dispatcher. The TMS BIZ automated tests execute against the socket server on Linux and Windows, so the module, middleware and WebSocket behaviour you rely on is verified on it — not just on the Windows dispatchers.

And on Windows, too

The socket server is cross-platform: it runs on Windows 32-bit and 64-bit as well, with the same code, the same properties and the same behaviour. (Internally it uses epoll on Linux and WSAPoll on Windows, which is about the only thing that differs.)

On Windows the Http.Sys-based server remains the recommended choice for high-load production servers — it's kernel-mode and integrates with the Windows certificate store. Reach for the socket server on Windows when:

• your application can't run administrative setup. Http.Sys needs netsh URL reservations and certificate bindings; the socket server binds plain sockets and needs none, so it runs under any user account.
• you want identical behaviour on both platforms — develop on Windows, deploy on Linux, with one configuration and no surprises.
• you prefer PEM certificates with SNI and hot reload over the Windows certificate store.

One more thing for Linux

A related fix in the same release removes another long-standing Linux annoyance: Sparkle now registers JOSE cryptography providers backed by OpenSSL 3, so JWT tokens signed with RSA (RS256/384/512) and ECDSA (ES256/384/512) work on distributions that no longer ship the legacy OpenSSL 1.x libraries — Ubuntu 22.04 and later, among others. This is what lets a TMS Sphinx server using RSA-signed tokens run on a modern Linux box. The providers are registered automatically and fall back to the previous implementation when OpenSSL 3 isn't available, so existing applications need no changes.

Conclusion

The socket server makes Linux a first-class deployment target for Delphi HTTP servers:

• One self-contained binary — no Apache, no nginx, no third-party libraries to install or keep updated.
• Everything a public-facing server needs — HTTPS with SNI and zero-downtime certificate reload, WebSockets, static files, keep-alive, chunked encoding, and built-in protection against oversized, slow and excessive requests.
• Fast, and steady under load — including the case that matters most, handlers that wait on a database.
• Nothing to rewrite — existing Sparkle, XData and RemoteDB modules run on it as they are.
• Cross-platform — the same server, the same configuration, on Linux and Windows.

It is now the recommended way to deploy TMS Sparkle, TMS XData and TMS RemoteDB servers on Linux.

A complete demo — dynamic endpoint, static files, WebSocket echo and optional HTTPS, in a single program that builds for both platforms — ships in the Sparkle distribution under demos/SocketServer.

To learn more, read the full Socket Server documentation and the what's new list, and visit the TMS Sparkle product page.

Build a Summer City Walking Tour Guide with TMS AI Studio, TMS FNC Maps and TMS FNC UI Pack

         Use coupon code :on the online order form to activate the discount! 

• TMS AI Studio for AI-generated tour content and speech
• TMS FNC Maps for geocoding, directions, markers, route drawing and GPX export
• TMS FNC UI Pack for the polished cross-platform user interface

From a City Name to a Personalized Walking Tour

• Museums
• Historical Places
• Architecture
• Parks & Nature
• Entertainment
• Shopping
• Food & Drinks
• Art & Galleries

                       

Screen for entering city or retrieve current location                                    The visualization of the calculated route
and categories of places you want to visit

AI That Calls Back into Your Delphi Code

• The POI name
• A short description
• The POI category
• A Wiki URL

This is achieved by a tool call that is setup:

var
  p: TCloudAIParameter;
begin
  CloudAI.Tools.Add;
  CloudAI.Tools[0].Name := 'addtourplace';
  CloudAI.Tools[0].Description := 'Add a POI name, description and Wiki Page URL for the walking tour to the list';
  CloudAI.Tools[0].OnExecute := ToolExecuted;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'POI';
  p.Description := 'The name of the POI';
  p.Required := true;
  p.&Type := ptString;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'Description';
  p.Description := 'A brief summary description of the POI';
  p.Required := true;
  p.&Type := ptString;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'Type';
  p.Description := 'The type of the POI from the list ' + CategoriesList([low(TPOICategory)..high(TPOICategory)]);
  p.Required := true;
  p.&Type := ptString;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'WikiURL';
  p.Description := 'The URL of the Wiki page of POI';
  p.Required := true;
  p.&Type := ptString;
end;

This gives the application clean, structured data instead of free-form text that still needs to be parsed afterwards. That is an important difference when building real applications: the AI becomes part of the workflow, while the Delphi application remains in control of how the data is stored, shown and processed.

Putting the Route on the Map

// build the waypoints array and ask the directions service to calculate a route 
// from starting place back to starting place with all waypoints in between
var
  i: integer;
  org: TTMSFNCMapsCoordinateRec;
begin
  org.Longitude := Places[0].Coord.Longitude;
  org.Latitude := Places[0].Coord.Latitude;
  SetLength(wp, Places.Count - 1);

  for i := 1 to Places.Count - 1 do
  begin
    wp[i - 1].Longitude := Places[i].Coord.Longitude;
    wp[i - 1].Latitude := Places[i].Coord.Latitude;
  end;

  FDirections.GetDirections(org, org, nil, '', nil, false, tmWalking, wp, true);
end;

A UI That Feels Like a Mobile Travel Companion

• Enter a city
• Pick one or more POI categories
• Generate the walking tour
• Review the generated places
• Open the map
• Tap a marker or list item for more information
• Listen to the description at the POI
• Export the route when needed

Let the Smartphone Speak at the POI

Why This Demo Matters

• Use AI to generate contextual, personalized content.
• Use mapping components to turn that content into real-world navigation.
• Use a rich cross-platform UI toolkit to make the experience easy and pleasant.

• Tourism apps
• Museum and campus guides
• City event applications
• Hotel concierge tools
• Conference venue guides
• Real estate neighborhood explorers
• Outdoor activity planners

A Productive Combination for Delphi Developers

Conclusion & share your city walks!