pip/pip-367.md
There are now many non-core, controversial features being added to Pulsar. The demand for these features does exist, but continuously adding too many features to Pulsar can make it more bloated and blur the semantics of some functionalities provided by Pulsar.
Here are some examples I encountered while participating in the community.
Some are questioned for potentially affecting the semantics of Pulsar, but they are ultimately added to Pulsar after thorough discussions and proper processes;
Pulsar is being used by many legacy systems and changing its semantics for specific usecases without considering consequences are creating a lot of pain and incompatibility problems for other existing systems and let's avoid doing it as we are struggling with such changes and breaking compatibility or changing semantics are just not acceptable. [0]
As for PIP-321 getting in without a consensus, I was one who had concerns with it (and still think poorly of it), but I don't think it was decided in violation to the rules. [1]
Some, after discussion, were abstracted and simplified, leaving the implementation details to the users. [2]
Additionally, when contributors proposed to contribute more features to the Pulsar Client, they encountered some skepticism. Although these concerns were addressed after discussions, they also reflected the ongoing dissatisfaction with the bloated API of Pulsar.
IMO the surface area the client already exposes is way too big. It feels any person that wanted to scratch their own itch just added their feature without holding back. This needs to be maintained. In OTel they have a contrib repo where people can contribute their plugin . In your case it's contributing a listener implementation. [3]
The suggestion of the OpenTelemetry contrib repository as a final proposal might be a good solution to this problem. It can prevent too many new features from being added to Pulsar, which would make Pulsar's semantics vague, giving it a kind of hodgepodge feeling. At the same time, it can also enrich the ecosystem of Pulsar. Only vital and critical features will be included in the main repository of Pulsar, while other personalized requirements should be placed in contributor repositories, similar to the OpenTelemetry contributor repository approach. [4]
Enrich the Pulsar ecosystem by adding a contrib repository for maintaining non-core requirements.
The main differences between Pulsar's main repository and contributor repositories typically include the following points:
Main Repository
Contributor Repository
In contrast, contributor repositories might include:
Core Feature Decisions: Deciding which features are core and which are non-core contributions is typically determined by project maintainers and community leaders based on the project roadmap and vision, and is not within the direct discussion scope of the contributor repository.
Feature Migration: Migrating non-core or semantically inconsistent features of Pulsar out of the core repository involves in-depth analysis and decision-making of the existing codebase, usually handled by the core maintenance team.
Provide a non-core code maintenance repository to collect plugin implementations, personalized features, experimental features, and user best practices.
The contributor repository is different from Pulsar's main contribution process. The contributor repository should take a more flexible approach to handle the integration of new features:
For specific repository design, please refer to: https://github.com/StevenLuMT/pulsar-java-contrib/blob/stable/README.md?plain=1
[0] - https://lists.apache.org/thread/87qfp8ht5s0fvw2y4t3j9yzgfmdzmcnz
[1] - https://lists.apache.org/thread/gzx4j9q0xdtcvrfvvq72t9tm2rt9h3r7
[2] - https://github.com/apache/pulsar/pull/22861
[3] - https://github.com/apache/pulsar/pull/22902#issuecomment-2168778056
[4] - https://github.com/open-telemetry/opentelemetry-java-contrib