Closed xuzhenbao closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
70548d6
) 88.85% compared to head (af208d8
) 88.88%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
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/
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-addedcelix_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.
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:
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
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.
It is replaced by #743
Resolves #612