Regarding option types, we can get half-way there by registering custom serializers. See: http://www.fssnip.net/ij
(Just remember to register the serializers before initializing your AppHost)
One problem is that generated DTO binding files will expose the property as a custom type called FSharpOption<T>. This might be okay for a F# client (although I haven't tested it), but it's inconvenient for other clients like C#. We've basically pushed the "semantic mismatch" from the server to the client.
A second problem is that even if ServiceStack.Text recognized supported Option<T> similar to the Nullable<T> type, what is supposed to happen when we have a non-option CLR reference type property on your DTO, like string? This could be null over the wire, and would somehow need to be validated to ensure it is not-null.
Brent
Regarding option types, we can get half-way there by registering custom serializers. See: http://www.fssnip.net/ij
(Just remember to register the serializers before initializing your AppHost)
One problem is that generated DTO binding files will expose the property as a custom type called FSharpOption<T>. This might be okay for a F# client (although I haven't tested it), but it's inconvenient for other clients like C#. We've basically pushed the "semantic mismatch" from the server to the client.
A second problem is that even if ServiceStack.Text recognized supported Option<T> similar to the Nullable<T> type, what is supposed to happen when we have a non-option CLR reference type property on your DTO, like string? This could be null over the wire, and would somehow need to be validated to ensure it is not-null.
It's an interesting problem!