Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APIv2: Changes in the next version of the API #66

Open
edenhill opened this issue Jan 30, 2014 · 2 comments
Open

APIv2: Changes in the next version of the API #66

edenhill opened this issue Jan 30, 2014 · 2 comments
Assignees
Milestone

Comments

@edenhill
Copy link
Contributor

edenhill commented Jan 30, 2014

This is a summary of changes that should go into the next version of the API (SONAME version 2).

C

  • Replace all error codes (rd_kafka_resp_err_t) with error objects (rd_kafka_error_t *).
  • Rename error_cb to event_cb - usable both for events and errors.
  • Provide a severity level in event_cb to let the application know the severity of the error.
  • Move log_cb to event_cb.
  • Logs, errors and events are all events and shall be treated equally through the event_cb.
  • Decomission all uses of errno. Consistently return error objects from all relevant functions.
  • Remove dr_cb.
  • Add flags field to rd_kafka_message_t, see issue Add producing batched messages #112
  • Add opaque to rd_kafka_message_t
  • Add errstr to rd_kafka_message_t, cant reuse payload in dr_cb.
  • Make rd_kafka_message_t a private type
  • Remove legacy consumer.
  • Add a richer error type that contains severity. ✅

C++

  • ABI safe design

General

  • Make murmur2_random the default partitioner to be consistent with Java producer.
  • Remove legacy configuration properties, such as the topic-level auto.commit.enable that is often confused with the new consumer enable.auto.commit
@ghost ghost assigned edenhill Jan 30, 2014
@winbatch
Copy link

As part of #1, would you consider converging/moving the logging callback into event_cb? If you think about it, a log represents information about an event. It would be good to:
- be able to subscribe to event callbacks of a certain type and/or minimum severity
- when the user receives the callback, they can choose to either ignore it, log it or do act on it.

@edenhill
Copy link
Contributor Author

Sounds like a good idea. Logging is a bit weird today because it is decoupled from the config object where everything else is set.

And as you say, all these things are really the same thing: errors, logs and events,

@edenhill edenhill changed the title Changes in the next version of the API APIv2: Changes in the next version of the API May 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants