test compatibility kit : Yes, that the purpose of AVRO-3591 <https://issues.apache.org/jira/browse/AVRO-3591> +1 for Required vs Optional.
For choice of PHP, Perl and Ruby : it's only a "personnal subjective advice" on languages i don't like; but, as i said before, with 100 developers, you'll get 100 different advises (that's why this kind of decision is hard to take). Le mar. 8 nov. 2022 à 13:38, Tim Perkins <[email protected]> a écrit : > Hi everyone, > > Can I ask why you would target PHP, Perl, and Ruby specifically for > removal? > > Thanks, > > -Tim > > > On Tue, Nov 8, 2022 at 6:50 AM Oscar Westra van Holthe - Kind < > [email protected]> wrote: > > > 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]> > > >
