[DISCUSS] How should we parse the Template JSON?

[dbwiddis]

Coming from https://github.com/opensearch-project/opensearch-ai-flow-framework/pull/26/files#r1329332685

In my initial template parsing implementation, I used the GSON library. It's Apache 2.0 open source. The latest version has no security vulnerabilites.

Given that we will be using clients, another option is the Jakarta JsonParser. It's licensed under EPLv2 (since Eclipse took over javax) and GPLv2 with classpath exception (from the Oracle days) so we'd need to add to our NOTICE file if we used it. It's probably "closer to the Java spec" though and would still be javax if Oracle didn't claim trademark on it.

@owaiskazi19 proposed using ObjectMapper from OpenSearch, but that class is marked @opensearch.internal and is a lot more heavyweight. It does give us more XContent style flexibility though. I think that there may be API versions that use that under the hood, such as org.opensearch.core.xcontent.XContentParser.

Jackson also has an ObjectMapper class (and frequent CVEs) and we should not use it. Which discussion let me to this issue which led me to GSON as a recommendation for plugins: opensearch-project/OpenSearch#5504 which led to opensearch-project/opensearch-plugins#211 which stated:

Based on the suggestions in the linked issue and my own research, a combination of GSON for JSON functionality and SnakeYAML for YAML functionality appears to be the best way forward.

Other one I'd consider is json-simple. It's also AL2.0 but it's very lightweight, small, no dependencies, and no vulnerabilities. If we're just using it for parsing (like my implementation in #26) and not doing fancy interaction with java objects, it's probably the best choice.

Open to any other ideas. Would like to get #26 merged with GSON for now and we can replace it later once this question is resolved.

[dbwiddis]

Closing this as I've implemented XContent-based parsing in #47