Netstring feature

[xuzhenbao]

Resolves #612

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (70548d6) 88.85% compared to head (af208d8) 88.88%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #726      +/-   ##
==========================================
+ Coverage   88.85%   88.88%   +0.02%     
==========================================
  Files         216      217       +1     
  Lines       24293    24376      +83     
==========================================
+ Hits        21585    21666      +81     
- Misses       2708     2710       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[PengZheng]

As mentioned in #612, the purpose of this netstring lib is to serialize/deserialize properties.

After reading netstring's spec([1]), I noticed that netstring is used to encoding byte string, for which we still lack an efficient in-memory representation like ccan/bytestring.

A second issue I found is related to our current efforts to add typing support to celix_properties: there is no typing support in netstring. This can be fixed by adopting "tagged netstrings" ([2]).

Then I have the third issue: by having a separate netstring library, what's the in memory representation of a tagged netstring? A bold thought turns up: what if we combine this nestring library into utils, and have celix_array_list, celix_properties, to-be-added celix_bytestring, and other types as the in memory representations of tagged netstrings?

I just record some thoughts here, which should not be viewed as anything like request for changes. But I do think the second issue is worth considering before merging this PR. @pnoltes @xuzhenbao

[1] https://cr.yp.to/proto/netstrings.txt
[2] https://tnetstrings.info/

[pnoltes]

As mentioned in #612, the purpose of this netstring lib is to serialize/deserialize properties.

After reading netstring's spec([1]), I noticed that netstring is used to encoding byte string, for which we still lack an efficient in-memory representation like ccan/bytestring.

A second issue I found is related to our current efforts to add typing support to celix_properties: there is no typing support in netstring. This can be fixed by adopting "tagged netstrings" ([2]).

Then I have the third issue: by having a separate netstring library, what's the in memory representation of a tagged netstring? A bold thought turns up: what if we combine this nestring library into utils, and have celix_array_list, celix_properties, to-be-added celix_bytestring, and other types as the in memory representations of tagged netstrings?

I just record some thoughts here, which should not be viewed as anything like request for changes. But I do think the second issue is worth considering before merging this PR. @pnoltes @xuzhenbao

[1] https://cr.yp.to/proto/netstrings.txt [2] https://tnetstrings.info/

tnetstring could be a nice fitting solution, but maybe we should also reconsider using JSON are serialization format? Downside is that we then make a JSON lib (i.e. jansson) a required lib for celix_utils and therefore celix_framework, but this will save some implementation effort.

[PengZheng]

tnetstring could be a nice fitting solution, but maybe we should also reconsider using JSON are serialization format? Downside is that we then make a JSON lib (i.e. jansson) a required lib for celix_utils and therefore celix_framework, but this will save some implementation effort.

I agree with the above assessment:

• JSON provides a well-defined and well-known serialization format.
• Using a high quality JSON implementation like jansson will save lots of implementation efforts.

As we already observed in #674, with typing support celix_properties will become more like JSON:

It will be nice to have array support.
If we went one step further to support embedding properties, celix properties will become json.

How about we focusing on typing support of celix_properties first? That is, getting #721 and #727 merged.
@xuzhenbao @pnoltes

[pnoltes]

How about we focusing on typing support of celix_properties first? That is, getting #721 and #727 merged. @xuzhenbao @pnoltes

+1, After PR #721 is merged I like to pick up the properties serialization and I see if the properties store/load can be done using JSON. This breaks backwards compatibility, but that is no issue because we are working on a new major Apache Celix version.

[xuzhenbao]

It is replaced by #743