Also not having any specific reason to not like Avro. The point of the JIRA is to have this very same discussion.
- Upgradeable protocols
-- Protobufs provides the same features, so this is not essentially a unique point for Avro.
-- For the simple and relatively stable need we have, even rolling our own on top of JBMarshaller could be an option.
- Cost of evaluation
I don't necessarily agree here. It has been a complex choice at the time but we're better aware of their differences now (also thanks to your investigation) and we have evolved our vision on what we need, so this cost won't be paid twice.
The performance aspect of the evaluation needs to be repeated anyway, even if we stick with Avro.
- Redefine the payload
I really like Hardy's ideas as a concept and I think we should explore these options. I'm not sure if it will be _that_ simple: if we run the remoting before the type converstion, we need to be able to transmit any type (including Tika streams and references to large external objects?), while if we run the conversion after conversion to Lucene objects, we're stuck with their model again.
Avro's benefits:
- Worked well so far
- We have most of it in place
- Provides protocol versioning
Negatives:
- Yet another dependency
- Seems it's not the most efficient
- Designed for cross-language compatibility (An overhead we don't need)
On top of JBMarshaller and Protobuf / ProtoStreams if we go for using our custom model we also have the option to roll our own, as what we would need is actually very simple.
|
