pnoltes commented on a change in pull request #185: Add custom serialization service for custom delete functions in RSA URL: https://github.com/apache/celix/pull/185#discussion_r404871825
########## File path: bundles/remote_services/remote_services_api/include/remote_custom_serialization_service.h ########## @@ -0,0 +1,36 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +#ifndef CELIX_REMOTE_CUSTOM_SERIALIZATION_SERVICE_H Review comment: Yeah, I starting to think that we should move away from descriptors and work our way to custom serialization services. Especially because I see more and more combination of C and C++ and then custom serialization would create more freedom how to handle this. Custom serialization services should not target an individual service (by id), but a message or service by fully qualified name and an optional version. I think we need to split the serialization for services and message. For service we need a (de)serialisation for the arguments and the return, for message only one set of de/serialization is needed. ```C //registered with properties targeted.service.fqn, targeted.service.version (optional) //mutiple registration are possible -> order by service ranking typedef struct rsa_custom_serialization_service { void* handle; const char* serviceFqn; const char* serviceVersion; int (*serializeArguments)(void *handle, void *args[] /*NULL terminated*/, char **out); int (*deserializeArguments)(void *handle, char *data, void **args[] /*output, NULL terminated*/); int (*freeArguments)((void* handle, void *args[] /*NULL terminated*/); int (*serializeReturn)(void *handle, void *returnType, char **out); int (*deserializeReturn)(void *handle, char *data, void **out); int (*freeReturn)(void* handle, void *obj); } rsa_custom_serialization_service_t; //registered with properties targeted.msg.fqn, targeted.msg.version (optional) and targeted.msg.id (??) //mutiple registration are possible -> order by service ranking typedef struct pubsub_custom_msg_serializer { void* handle; unsigned int msgId; const char* msgFqn; const char* msgVersion; celix_status_t (*serialize)(void* handle, const void* input, void** out, size_t* outLen); celix_status_t (*deserialize)(void* handle, const void* input, size_t inputLen, void** out); //note inputLen can be 0 if predefined size is not needed void (*freeMsg)(void* handle, void* msg); } pubsub_custom_msg_serializer_t; //note almost the same as the current pubsub_msg_serializer_t ``` Descriptors can still be supported, but then as an extender pattern. So a json (descriptor) serializer would monitor the bundles and register a service for every descriptor found. If there is already a serializer for that descriptor, skip it. PubSub admin will need to ensure that the custom serialization services are map by msg id instead of names. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
