[
https://issues.apache.org/jira/browse/MINIFI-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Rosander updated MINIFI-278:
----------------------------------
Description:
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]
was:
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
> 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
>
> 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)
