Hello, I don't see a need to remove any SDK for now. As with any other open source project the development is driven by users' needs. IMO it is not necessary a feature to be added to all SDKs at the same time, i.e. the SDKs don't need to evolve in the same pace. Whenever a user needs some functionality (s)he can help to implement it.
The bigger problem we have now is that some of the SDKs don't have active maintainers to review and merge users' contributions. For example the C# SDK received many PRs but there is no knowledgeable committer to approve them. My current approach is to merge such PRs if they are approved by at least two C# contributors. A TCK would be definitely helpful but again if there is no one to merge PRs I don't see who will implement it for the respective SDK. Martin On Tue, Nov 8, 2022 at 3:34 PM Christophe Le Saëc <[email protected]> wrote: > 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]> > > > > > >
