1. My thinking was that it represents the in progress sending of a record,
but I take your point. It sounds like the consensus is that it would be
better to have the return type be something like Future<RecordMetadata>
where the metadata has the offset/topic/partition and the Future has the
exception if there is one.
2. Yeah I totally agree. The question here is whether we provide constants
for the config strings or just refer people to the docs. People have
requested constants. There are some issues. It means that removing configs
is not backwards compatible. That javadoc does give the string of constant
3-6. Agree, all of these need to be reconsidered more carefully.
8. Ack, actually the problem is that that should be under internals and not
in the generated javadocs at all. That is an internal class, what you
actually get is a RecordSend.
9. Yeah it's an internal class so it maps more closely to the response from
the server. The server doesn't give the offset for each record but rather
just the base offset since the offsets are guaranteed to be sequential.
10. This is a point worth discussing. I have used the scala style method()
rather than the java style getMethod()/setMethod(). My objection to getters
and setters is that they imply something about the implementation (namely
that you are getting and setting something) and somehow because of that
naming people tend to make one getter/setter per member variable instead of
exposing the higher level operations on the type. I realize this is at odds
with basically the rest of the Java code in the world. Either way let's
pick a style and use it throughout.
On Wed, Jan 29, 2014 at 2:41 PM, Chris Riccomini <[EMAIL PROTECTED]>wrote: