I want to support different versions of a client from the same server. The reason is that we cannot always guarantee a user is running the latest version of our software. Therefore clients based on different RODL files will be active at the same time. The server is code first/.Net, the clients are Delphi.
I want to adept the serialization process on the server and send only those fields that match the version of the clients RODL file. I want to do this by creating a custom serializer (inherits from
BinSerializer) and filter the fields. Do you think this can be done, or is there another (better) way of achieving the same?
This solution may work, but it will be very fragile and will require way too much code.
Proper support will require some changes (we’ll need to add several extension points). You’ll need to wait for a couple of days until we’ll be able to say a proper ETA.
Btw there is question - will you need to be able also to READ client-sent versioned structures or this solution should be able only to SEND data out?
Well, that required more efforts than I expected, still the result looks quite good as for me:
Client-side
Client uses conventional BinMessage and generated _Intf files. The only requirement for the client is to provide API version it is going to use. This info has to be provided during login process or at any time before versioned structures are used. In my prototype I used a Login method for this purpose, however a separate method in the main service would also work.
So the changes required in the existing client apps to add support versioning are minimal. Also a very important thing is that clients apps can run on any platform supported by Remoting SDK - from .NET Core to iOS.
Server-side
Some support code is required. It is not specific for a concrete app, however I am not sure if it needs to go into the core SDK codebase. IOW there is a set of source code files that you’d need to add to your server app project to add the versioning support.
After all these changes a versioned structure definition looks like
public class TestStructureOut : VersionedStructure
{
public String CommonValue1 { get; set; }
[ApiVersion(1)]
public String ValueV1 { get; set; }
public String CommonValue2 { get; set; }
[ApiVersion(2)]
public String ValueV2 { get; set; }
}
This definition contains 3 properties that are available for API versions 1 and below and 1 property that is available only for API versions 2 and up.
In the service method that uses this structure
[ServiceMethod]
public TestStructureOut DoSomething(TestStructureIn someValue)
{
var result = new TestStructureOut();
result.CommonValue1 = someValue.CommonValue;
result.CommonValue2 = someValue.CommonValue + " " + DateTime.Now;
result.ValueV1 = someValue.ValueV1.ToUpperInvariant();
result.ValueV2 = someValue.ValueV1.ToLowerInvariant();
return result;
}
field ValueV2 will NOT be sent to an API ver. 1 client despite it is set in the code and is present in the server RODL.
Limitations:
This feature required several changes in the core SDK to add extensibility points required to make it work. So it won’t work even on the latest Beta, it will require even more recent build
Server will always expose RODL for the latest API version
How does that sound for you? If you want to try this feature in the work then please drop a mail to support@ with your account name. Then min-next-week (or even earlier) we’ll be able to provide you a pre-Beta build with the required changes + a sample app projects set (a server and clients for ver.1 and ver.2 APIs)
Your design choices where exactly what I was thinking of. We already communicate a version number in the login method. Now we abort the client when this version does not match. I also thought about using attributes to control fields per version.
So yes, I would like to test this myself and send a message to support.