Import consumer from Kafka-go

[yaziine]

Fix #10.

Notes:

• the logging and metrics have been removed
• new MetricsHook interface that can be passed to receive metrics

[tealeg]

We still need to move consumer.Stop from Kafka-go as a well.

[tealeg]

👍

[tealeg]

🌷 this isn't a great comment, but I'll pick this up in the documentation work.

[tealeg]

🌷 this is the sort of thing that we might want to pull out of the Consumer type and make public if we want people to be able to user felice in a modular way.

[yaziine]

For example, if they want to do some specific task/changes in the message?

[asdine]

The consumer lacks logs, especially debug logs describing the lifecycle of the goroutines, consumption attempts etc. Even though some of these will be written in Kafka-Go, I'm not sure it will be enough.

[tealeg]

If we add logging we should do it via an interface. It's probably OK to expect a structured logger (after all you could write an adapter to use a non-structured one if you really wish). Perhaps this is something for a separate branch?

[asdine]

I'm not sure we should go as far as abstracting logging: This is an opinionated library and IMO this kind of library can choose how it logs (whether by using the std logger or a third party library) and simply allow the user choose the output and the level if any; Sarama and a lot of other libraries already do that.
Logging the right information at the right place is a feature provided by the library and not having to abstract that would allow us to be more flexible.

[yaziine]

Maybe we can do as Sarama does. By default, it logs to ioutil.Discard but if the user wants to retrieve the logs, he has to set the Logger variable to redirect the output where he wants. WDYT guys?

[asdine]

Something like that would be cool yeah, a library shouldn't print anything by default.

[yaziine]

a library shouldn't print anything by default

It's for why I want to remove the loggers because it's not common (based on my experience) to have library logs as a project will do (think of regula for example).
But the way of Sarama is good I think. Let's wait for @tealeg input.

[asdine]

It's for why I want to remove the loggers because it's not common (based on my experience) to have library logs as a project will do (think of regula for example).

Not printing by default and not providing logs are two different things. It's important for a library to log when it's doing internal complex stuff, regardless of the output, and it is the user's choice to display these logs or not.

[yaziine]

For me (until these days) a library didn't have to log. If something goes wrong, it just returns errors and the users will manage that with logs and so on. But now it's more clear for me.

[tealeg]

I like the ioutil.Discard approach - let's do that.

[asdine]

🌷 What is the reasoning behind having c.handlers as a pointer since all we do is instantiate it like this? Shouldn't we simply use a value field instead of a pointer field?