Add celix_properties_t and celix_array_list_t pointer type to dfi

[xuzhenbao]

This PR aims to add celix_properties_t* and celix_array_list_t* to the dfi. In addition, in order to reuse the serialization code of celix_array_list_t, this PR moves the serialization code of celix_array_list_t in properties_encoding.c to celix_array_list_encoding.c.

There is an issue that needs to be discussed in the PR. When libdfi serializes celix_properties_t or celix_array_list_t, it will call celix_properties_saveToString or celix_arrayList_saveToString to convert them into a JSON representation string, and then convert the string into a JSON-object. (See the jsonSerializer_writeProperties function for specific code)
There is a process of converting JSON-object to a string and then converting the string to a JSON-object, which may affect performance. If add a new interface celix_properties_saveToJson(const celix_properties_t* properties, int encodeFlags, json_t** out) to celix_properties.h, which directly converts celix_properties_t to a JSON-object, this can reduce the operation of converting JSON-object to a string. But it will make the json_t type part of the Celix::utils external interface.

[pnoltes]

Overall nice improvement for libdfi :)

I am not sure if a single descriptor for array list (a) is enough.

[pnoltes]

nitpick: word logged is split over 2 lines

[pnoltes]

Nitpick: The properties and array_list types have been added as potential targets for const=true, but the accompanying text currently only references char*. I suggest we rephrase it for clarity, something like:

Normally, a text, properties, or array list argument will be handled respectively as `char*`, `celix_properties_t*`, or `celix_array_list_t*`, implying that the callee is expected to take ownership. However, if the `const=true` annotation is used, these arguments will be handled as `const char*`, `const celix_properties_t*`, or `const celix_array_list_t*`, indicating that the caller retains ownership of the string/object.

[pnoltes]

Is a descriptor a enough for array list?

With the current implementation of array list, the array element type is fixed at creation. Using the array list wrong (e.g. getLong, when it is a string) will lead to an assert failure.

With dfi you can serializer / deserialize array list of any element type, but the underlying code will assume a element type (or needs to use defense programming by checking the element type before continuing).

Maybe it is better to use different dfi descriptor for the different array lists (string, long, double, boolean and version).

@xuzhenbao and @PengZheng WDYT?

[PengZheng]

Maybe it is better to use different dfi descriptor for the different array lists (string, long, double, boolean and version).

Or a together with type annotation using meta-info.
And then the dfi could do the type-checking.

Will it make the local service different from the remote ones?
For a local service, we must do the type-checking anyway.
Or shall we make array element type assertions instead so that local/remote services could be unified?

[pnoltes]

A a with annotations sound good.

IMO there is a different between local calls and remote calls. Generally speaking local calls can be trusted (although here is also room for improvement (static bundles / signed bundles, because you can dynamically install new bundles). A remote call is less trustworthy, so IMO crashing (assert fail) is then not an option.

To be honest, I am still unsure if the current array list implementation is the correct approach. Another option could be to really split up the public array list API in a long, double, string, pointer, boolean, version array. So something like: celix_long_array_list_t with functions like celix_longArrayList_get, etc.

The underlying code can still be the current array_list, but the public api only provided wrapper around the generic impl.

If we want to do that, this can and should be done separate from this pull request.

[PengZheng]

A remote call is less trustworthy, so IMO crashing (assert fail) is then not an option.

I totally agree.

To be honest, I am still unsure if the current array list implementation is the correct approach. Another option could be to really split up the public array list API in a long, double, string, pointer, boolean, version array. So something like: celix_long_array_list_t with functions like celix_longArrayList_get, etc.

Imagine that we are dealing with json rather than array list or properties, there are at least two options:

1. Let the service implementation perform type checking manually, calling json_is_array etc.
2. Delegate type checking to the framework via json schema, which is essentially the same as type annotation approach. Then it will be OK to add various type assertions to the service implementation (for documentation purpose), which may be remote or local.

Both should work.

[pnoltes]

Using JSON Schema is indeed a good option. It helps avoid overly defensive programming and ensures validation occurs before messages are deserialized.

However, isn’t the DFI descriptor already a form of serialization schema? But less focused on the serialized format itself and more on the memory representation (excluding padding and alignment details, which are handled by libffi).

Given that libjansson does not support JSON Schema, I believe it would be better to extend the DFI type system to be more explicit. This could also open the door to future enhancements, such as adding support for annotations like min/max.

One potential downside of this approach is that it would no longer be possible to generate a descriptor string directly from a header file. Currently, - I think - this is possible (e.g., parsing a celix_array_list_t* field by adding an a descriptor type). This is why I think it might be better to replace celix_array_list_t with type-specific versions.

For now, my proposal is to keep the a descriptor for this pull request. If we decide to replace celix_array_list_t with type-specific versions in the future, both the DFI and serialization logic would need to be updated accordingly.