[ https://issues.apache.org/jira/browse/AVRO-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353906#comment-15353906 ]
Doug Cutting commented on AVRO-1704: ------------------------------------ I think all the methods are useful but some of them (e.g., non-reuse) will always be implemented by boilerplate and are thus not core to the interface, but rather something more suitable for a base class. An abstract base class would still permit independent alternative implementations. The only additional power an interface has is that one can implement multiple interfaces. But interfaces don't let you implement convenience methods, nor do they permit compatible evolution (if you ever add or remove a method, you break implementations, because you cannot provide default impls). But if you feel multiple inheritance is important here, then it's probably easier to stick to an interface than, e.g., refactor into encoder/decoder provider classes that are separate from the user-invoked classes or some other way to avoid such boilerplate implementations. Encoding to a ByteBuffer should be thread-safe, since it has no caller-visible state, no? > Standardized format for encoding messages with Avro > --------------------------------------------------- > > Key: AVRO-1704 > URL: https://issues.apache.org/jira/browse/AVRO-1704 > Project: Avro > Issue Type: Improvement > Reporter: Daniel Schierbeck > Assignee: Niels Basjes > Attachments: AVRO-1704-2016-05-03-Unfinished.patch, > AVRO-1704-20160410.patch > > > I'm currently using the Datafile format for encoding messages that are > written to Kafka and Cassandra. This seems rather wasteful: > 1. I only encode a single record at a time, so there's no need for sync > markers and other metadata related to multi-record files. > 2. The entire schema is inlined every time. > However, the Datafile format is the only one that has been standardized, > meaning that I can read and write data with minimal effort across the various > languages in use in my organization. If there was a standardized format for > encoding single values that was optimized for out-of-band schema transfer, I > would much rather use that. > I think the necessary pieces of the format would be: > 1. A format version number. > 2. A schema fingerprint type identifier, i.e. Rabin, MD5, SHA256, etc. > 3. The actual schema fingerprint (according to the type.) > 4. Optional metadata map. > 5. The encoded datum. > The language libraries would implement a MessageWriter that would encode > datums in this format, as well as a MessageReader that, given a SchemaStore, > would be able to decode datums. The reader would decode the fingerprint and > ask its SchemaStore to return the corresponding writer's schema. > The idea is that SchemaStore would be an abstract interface that allowed > library users to inject custom backends. A simple, file system based one > could be provided out of the box. -- This message was sent by Atlassian JIRA (v6.3.4#6332)