Commit graph

5 commits

Author SHA1 Message Date
cfdb659ccb BufferProvider: prototyping for a proxy-BufferProvider
This is an implementation experiment to validate the improvements
and internal clean-up. Previously, I was unable to implement such a
forwarding proxy buffer provider, as would be required for the
intended harmonisation of the `OutputSlot` interface with `BufferProvider`

With the reworked verison of the BufferProvider standard implementation
it seems straight-forward to...
 * define a »Buffer Type« that marks any of the prepared buffers to pass-through
 * use the resulting Buffer Descriptor together with a rigged storage backend,
   that just returns the ''local tag'' as buffer adress
2026-02-22 00:30:45 +01:00
722c12e312 BufferProvider: assess status and consider approach to OutputSlot (see #1395)
The first round of the [ticket:1410 BufferProvider clean-up] is roughly complete.
 * a much cleaner diagnostic interface has been defined and implemented
 * this allowed to modernise the `DiagnosticBufferProvider_test`
   and the `BufferProviderProtocol_test`
 * the implementation scheme has been split in two realms
 * the old heap-memory based implementation has been re-arranged,
   so that the aforementioned tests are **green** again.

Now is the point to draft a solution to get the interfaces of
`BufferProvider` and `OutputSlot` aligned, so that the latter
can expose its lifecycle through the former.

Today, I have analysed various aspects and developed a pathway
to get into that task, and next I will reshape the previously
failed `OutputProxyProvider_test` into a prototype to
validate this idea
2026-02-20 00:21:29 +01:00
c21ddc1844 BufferProvider: looking for ways to disentangle the implementation (see #1410)
The outward interface has stood the test of time quite well.
But the back-side towards the implementation is a tangled mess,
presumably due to being developed from prototyping code: the
actual implementation is completely overgrown by diagnostics
and test instrumentation, since running in unit test setup
was the only actual usage of this code ever since.

My first attempt with decomposing into a decorator-chain failed.
Thus the new line of attack is to introduce two implementation
pillars right from top-level
- `BufferStage` : the state and metadata handling
- `BufferStore` : the storage backend
These are defined as nested interfaces, and the further refactoring
starts with subclassing everything, nested as it is.
2026-02-10 00:41:41 +01:00
d888891d84 clean-up: trifles 2025-06-07 23:59:57 +02:00
555af315b3 Upgrade: improve Doxygen parameters and treat some warnings
- remove obsolete configuration settings
- walk through all settings according to the documentation
  https://www.doxygen.nl/manual/config.html
- now try to use the new feature to rely on Clang for C++ parsing
- walk through the doxygen-warnings.txt and fix some obvious misspellings
  and structural problems in the documentation comments.

With Debian-Trixie, we are now using Doxygen 1.9.8 —
which produces massively better results in various fine points.

However, there are still problems with automatic cross links,
especially from implementation to the corresponding test classes.
2025-04-27 05:00:14 +02:00
Renamed from tests/core/steam/engine/buffer-proxy-provider-test.cpp (Browse further)