I have no objections to the name. A centralized repository dedicated to
this cross-language testing is appealing.
Nonetheless, I would like us to discuss the architecture of this repo and
the test scenarios it will address.
Here are some of my initial thoughts. Please feel free to weigh in! 🙂
When this cross-language testing started we had only two languages: Java
and C++. It was a simple exchange of sketch images (*.sk) where Java would
load and test the images generated by C++ and C++ would do the reverse.
Now that our library implements 6 different languages this simple scheme
has real limitations regarding scaling and maintenance.
Perhaps now is the time to rethink our objectives and how we want to
implement cross-language testing.
Let me try to state what I think our objectives are:
DATA:
Let:
*L_a *:= a specific Language
*L_b *:= a different language
*Sk(S, T, L) *:= Serialization image of Sketch *S*, using test algorithm *T*,
created by Language *L*
*{T}* := a range of test algorithms
- For every sketch type *S_i* implemented in *L_a* it should generate a
range of sketch images of test algorithms, *{T}*, or
*{Sk(S_i, {T}, L_a)}. * The S*_i, T,* and *L_a* of a specific *Sk* could
be documented in the sketch name (or in metadata somehow).
- It might also be useful to document the release version of *L_a *that
generated the sketch and possibly other information.
- For every sketch type *S_i *impemented in *L_b *it should read and
test *Sk(S_i, {T}, L_a).*
This does not require every language to implement all sketches—that is
simply not feasible—but hopefully we will reach a point where most of the
languages implement at least one member of the key sketch families:
cardinality, quantiles, and frequency.
We want to test each language's ability to correctly generate these sketch
images and its ability to read and verify images generated by other
languages.
This implies multiple sets of sketch images generated by each of the
languages. Because we cannot rely on exact binary reproducibility of these
sketch images, I don't see a way around this.
The above is largely based on our historical testing approach.
What if we enclosed each sketch image in a container that would have space
for additional metadata, like:
- The release version of the generating language
- Code or Pseudo-code describing the generating algorithm
- Test criteria
Ideally, a smart container could simplify managing all this testing so that
every language doesn't need to know what is inside; it just picks up the
container, runs the test using the given criteria, and reports pass or
fail. I don't know how to do this, but it is fun to think about.
Thoughts?
Lee.
On Tue, Jul 21, 2026 at 6:04 PM tison <[email protected]> wrote:
> Thanks for your feedback. After some consideration and discussion with a
> few contributors, I'm going to create the repo of name "datasketches-tck"
> which means DataSketches Technology Compatibility Kit. This follows the
> impression of Java's Technology Compatibility Kit [1] and for DataSketches,
> it would contain test suites of compatibility among datasketches
> implementations, including mainly the serialization format.
>
> [1] https://en.wikipedia.org/wiki/Technology_Compatibility_Kit
>
> The initial implementation contains serialization snapshot of Java and
> C++, and we shall be able to add Go's and Rust's snapshots later. The
> generator is already present at [2] while I'd cut the code into one
> generator per language.
>
> [2]
> https://github.com/apache/datasketches-rust/blob/ee6e1cc432555c3562274ec36fc2dd6419b96701/tools/generate_serialization_test_data.py
>
> Naming is hard and it takes all this time to figure out how to name the
> repo to define its proper scope.
>
> I'd share the link to the initialized repo on the list this week or the
> next. Welcome to drop your comments if you have any additional ideas.
>
> Best,
> tison.
>
>
> Filippo Rossi <[email protected]> 于2026年5月26日周二 01:28写道：
>
>> Sounds very good!
>>
>> I think this will be a great way to validate the sketches serialised from
>> datasketches-rust, which currently are untested across the language barrier.
>>
>> Thanks tison!
>>
>> Best,
>> Filippo
>>
>> On Mon, May 25, 2026, at 16:48, tison wrote:
>>
>> I'm going to create the repo and demonstrating the tasks, as well as
>> integrating datasketches-rust with it in recent weeks :D
>>
>> Best,
>> tison.
>>
>>
>> tison <[email protected]> 于2026年5月20日周三 09:41写道：
>>
>> Hi,
>>
>> I'm seeking a consensus to have a datasketches-snapshots repo for hosting
>> code and snapshots for delivering
>> https://github.com/apache/datasketches-rust/issues/10
>>
>> Previous discussion -
>> https://lists.apache.org/thread/5ppjzrc151n387n4xfgpx1cxnhcv2sbk
>>
>> The first step would be generating snapshot and save them for reusing in
>> CI.
>>
>> Then we can review the generator and test cover matrix later, for issues
>> like
>> https://github.com/apache/datasketches-rust/pull/132#pullrequestreview-4319258129
>> .
>> Best,
>> tison.
>>
>>
>>
