My application is configured to use JsConfig.TimeSpanHandler = TimeSpanHandler.StandardFormat and I have a DTO that returns an object that contains a TimeSpan property. The TimeSpan property is nil when calling this DTO from the Swift client because only the Xsd:Duration format is currently supported. I was able to workaround this issue with the Java client but I cannot apply a similar workaround for the Swift client as I do not want to modify the JsonServiceClient.swift.
Do you plan to support the TimeSpan .Net format in the Swift client? I may be able to send you a pull request for this if you want.
No there’s no plan to add support for more non-default formats for TimeSpan, it already supports XSD and being sent as a double which is what NSTimeInterval is an alias for, what it needs to convert into and what the TimeSpan.java impl wraps around.
If you’re concerned with how TimeSpan’s look on the wire you could send a string instead.
You can add a feature request for it, but I want to avoid pushing the complexity of handling non-default customizations for each datatype into every client library. If it’s just added in 1, it might encourage use of non-defaults which hurts interoperability as the different client libraries will lack feature parity.
In that case can you remove the “feature” to change the TimeSpan format from ServiceStack altogether? It’s a bit weird that I can configure the host to output a format that is not understood by the different clients.
No, breaking existing Customer solutions by removing dependent functionality is never an option. There are valid uses of allowing easy configuration of server serialization without forcing every client to support every non-default config permutation.
If you configure the Server you also need to configure the Client with the same settings, which is only available in .NET clients since it’s naturally supported. Whilst other customization’s are the default behavior in different platforms that the service is primarily serving, removing the need for configuration on the client.
There’s negative value in introducing a customizable client configuration for every platfform Add ServiceStack Reference will support, it adds unnecessary complexity, reduces it “just working” and introduces another concept developers need to know about.
For maximum interoperability stick with the defaults, that’s what’s going to be supported everywhere.