#994 Haxall test tooling

Chris Breederveld Tue 21 Jun 2022

Hi all,

I love the initiative to open source the SkySpark core code in the Haxall library, so vendors can easily extend this logic with their own implementation.

However one concern I have is that the JVM requirement and building additional logic with Java or Fantom may hold back some vendors from straight up using it.

It would therefore be useful to make additional libraries available in other popular languages, like C++, C# and Python. However to facilitate that it would be very useful to have a tool that can test the capabilities of such an implementation for both implementation completeness and correctness. Not only for new implementations, but also to implement future changes.

Is there any plan to create such a tool (similar to the W3C Html validator for example) or do you have any other insights on how to make broader adoption more accessible?

Chris Breederveld Tue 20 Sep 2022

Hey, does anyone have insights about this question?

Brian Frank Tue 20 Sep 2022

I don't follow what exactly you are thinking.

Do you mean a test suite for the file formats? We could do something like the YAML test suite which is pretty comprehensive.

Or did you mean more like a plug-fest testing of the HTTP API?

Chris Breederveld Tue 20 Sep 2022

Hi Brian,

No I'm talking much bigger; the actual Haxall framwork. Currently this framework is an open source project, written in Fantom.

The main goal of this framework, as far as I understand, but correct me if I'm wrong, is to make it easy for vendors to implement the Project Haystack interface.

However as it is currently only possible to build an interface in the Fantom, Java or Javascript languages, it forces those vendors to chose only from that set.

I think it would be beneficial if there are also Haxall frameworks in other popular languages available to make the framework more accessible. However to align those frameworks, some unit testing system could be used to verify if they behave as expected.

Brian Frank Wed 21 Sep 2022

Oh ok - well that might be a different discussion. Haxall goes far beyond what is in Haystack itself. Most open source libraries are tackling the core: data structures, I/O encoding/decoding, HTTP API, and the def model. Although I believe currently only Haxall and J2's TypeScript lib does the last one. And soon we will have the proto compiler and validation tools.

Haxall on the other hand is a complete platform: database, extension management, user management, connectors, historization engine, task scheduling, UI, etc. So its probably an order of magnitude more software than the libraries focused on Haystack types, I/O, and HTTP API.

My expectation is that most people with existing platforms just need the Haystack stuff to glue to their existing system. But for greenfield development, I agree - a complete platform is ideal!

Fantom targets the Java and JS ecosystems. Not sure how you get to others unless someone writes a similar platform or ports the code.

Although for .NET you may not be aware that Fantom was originally designed to run on the JVM and CLR. So almost all the core functionality has CLR bindings in C# already. We don't maintain it anymore ourselves. But the work to make the Fantom version of Haxall run on .NET would probably be far easier than porting the entire thing to C#. If you are interested in that, you can contact me offline.

Separately we have prototyped transpiling Fantom to "clean" Java, C#, TypeScript, and Python source code (since it was originally designed from the ground up for to be a portable language). But its more of a future project we are considering.

Chris Breederveld Wed 21 Sep 2022

Hi Brian,

I am not personally interested in implementing Haxall in C#; my main goal is to have a way to have our many many vendors implement a Haystack interface to their hardware.

As these suppliers have various software teams, having multiple languages to pick from would make this an easier step than to also have them build of the plumbing from the ground up.

For example; we rely heavily on the Haystack C# client library for communication with SkySpark servers. This library is currently maintained by us with some improvements coming in from the community. However, maintaining this library is not our main goal and takes away time from our core business, it also shows how much effort needs to go into implementing some of the core concepts, like authentication.

Therefore, if there is a way vendors can jump on board the Haystack train with minimal impact to their business, by using off-the-shelf and proven technology this could have a big impact on adoption.

I think the idea to transpile the library is a good one, as then you at least know the logic is guaranteed to be the same on all platforms and tested with the similarly transpiled test cases.

Login or Signup to reply.