If we use file protocol for a named pipe url, it will expose platform differences to users and also test cases. Internal implementation also need to do some conditional compilation.

As of now, we resolved this issue by stripping off file protocol part from the url and append it to the default named pipe path.

With the prospect that unified APIs for cloud storage object will be defined at the storage engine layer and command layer will not parse the url field and pass it along to the storage engine layer as is, url field name is maintained.

One issue with this approach is url is not URL anymore since it does not conform to the file protocol specification in URL.

One suggestion is to rename the url field to pipeName when storageType is "pipe".

Benefits of renaming is that we can avoid file:// protocol check and stripping off file:// which are almost two liner changes and probably we can avoid some people's raised eyebrows about the behavior.

This field name change will require changes to server code here and there and a lot of test cases and also need downstream changes email.