[
https://issues.apache.org/jira/browse/MINIFI-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985400#comment-15985400
]
Kevin Doran commented on MINIFI-278:
------------------------------------
[~bryanrosan...@gmail.com] This is interesting. I agree with the pros/cons you
identified.
I will check out your branch when I get a chance and play with it some.
Some questions regarding the C++ and Java project plans. When we get around to
Avro/Protobuf schemas for sending configurations, how do we envision that will
work from a dependency perspective across Java and C++ repos/projects? Would
one depend one the other for the avro/protobuf schema, or would a copy of
schemas exist in each that needed to be kept in sync? A third option I suppose
is to put common files such as schemas into a stand-alone location that both
Java and C++ could depend on. I'm interested in the answer to that question as
it has implications if we add a layer of abstraction with the
single-source-of-truth schema... as you say, "the metadata could also be useful
on the minifi-cpp side".
I think at the root of my question is this: Is it the intention that minifi and
minifi-cpp eventually get to the point that they have feature parity and
more-or-less stay in lock-step w.r.t releases and features... or,
alternatively, would it be preferable to plan for the possibility that they
evolve in a more decoupled fashion at their own pace. If the latter, applying
DRY practices cross-project probably does more harm than good, though there
would certainly be an opportunity here just within on language if you could
single source of truth for java codegen + protobuf schema + avro schema.
> Single source of truth for ConfigSchema structure
> -------------------------------------------------
>
> Key: MINIFI-278
> URL: https://issues.apache.org/jira/browse/MINIFI-278
> Project: Apache NiFi MiNiFi
> Issue Type: Improvement
> Components: Command and Control
> Reporter: Bryan Rosander
> Attachments: configSchema.json
>
>
> Motivation:
> We currently have ConfigSchema implementations in both C++ and Java code and
> will probably want a more compact binary format (Avro, Protobuf, etc) for
> sending configurations over the wire.
> Having many different hand-coded ways to represent the same functionality
> seems tedious and error-prone.
> One alternative:
> Json file declaring the structure of the configuration objects as well as
> basic metadata (type, default, required). This could be used to autogenerate
> the Java code required to serialize and deserialize these objects to/from
> yaml as well as the Avro or Protobuf schema and the glue code between the two.
> This metadata could also be useful on the minifi-cpp side.
> Pros:
> Single source of truth
> Less tedious copy/paste code
> Automagically keep other formats in sync
> Cons:
> Custom code generation - higher barrier to entry in codegen module, code
> generation isn't always a good idea
> [Branch with partial
> implementation|https://github.com/brosander/nifi-minifi/blob/MINIFI-278/minifi-commons/minifi-commons-schema/src/main/schema/configSchema.json]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
