Hi everyone, Feature parity is indeed very difficult, and IMHO practically impossible. I do think however, we'll need some requirements on implementations to ensure maintainability and a minimum level of features.
Prerequisite for all this is a TCK (test compatibility kit) with common schemata and a dataset (both 'readable' and encoded). This proves interoperability, and supported features. A good test set also makes implementing features in different languages easier. For maintainability we should at least require a knowledgeable committer, and perhaps also a minimum amount of changes to keep knowledge current. For committers I happily defer to the PMCs. On changes I agree with Christophe to remove support for PHP, Perl and Ruby. Below is my opinion on features (the required features are perhaps too minimal): Required: - Parse JSON formatted schemata, supporting only the features of the *parsing canonical form*, plus aliases - Schema resolution/evolution on all supported schema features - Read/write Avro files using the binary or JSON encoding - Encode/decode records using the single-object, (raw) binary or JSON encoding Optional: - Construct schemata using an API and/or builder pattern - Parse JSON formatted schemata, supporting all features - Format schemata into all formats supported for parsing - RPC using Avro protocols - Parse schemata / protocols from IDL or other formats - Generate code from schemata (like SpecificRecord subclasses in Java using the Maven or Gradle plugins) - Schema resolution/evolution on logical types with different underlying presentations (e.g. decimals from fixed or string to bytes) - ... all other features (like generating random data) Kind regards, Oscar On Tue, 8 Nov 2022 at 09:52, Christophe Le Saëc <[email protected]> wrote: > Avro is currently implemented in 10 languages, this leads to some issue : > > - For a new feature, it's difficult to add it everywhere. > - Difficult to ensure that each implementations have same possibilities. > - Bug fix can be hard (This JIRA > <https://issues.apache.org/jira/browse/AVRO-3591> try to solve by > adding > common test system). > > On the other hand, it can be hard to decide which implementation to remove; > and each developer & user would will have different advice (*Mine would be > to remove perl, php and ruby*). > May be a doodle like system would be a solution (for each language, get pro > & cons; and remove an implementation when there are more than 80% cons). > > WDYT ? > -- ✉️ Oscar Westra van Holthe - Kind <[email protected]>
