Prove design for rehydration of Operation and Operation<T>

[annelo-msft]

Operation types must provide a constructor that allows users to access an existing LRO.

Currently, protocol methods and their convenience APIs that start/complete long-running operations return either Operation or Operation<T>. Neither of these types provides a way to access an existing LRO as required by the guidelines.

This issues tracks the work to provide a proof of concept that we can implement this functionality. An implementation is not required for DPG GA, but will be a DPG v1.1 feature.

[annelo-msft]

Related to Azure/autorest.csharp#2158

[ArthurMa1978]

Is this depend on Azure/autorest.csharp#2231 ?
And can we have this done in May?

[annelo-msft]

Is this depend on Azure/autorest.csharp#2231 ?

Having #2231 would speed up the implementation of this, and help with design, but it is not strictly required.

And can we have this done in May?

We are working toward this. I have created a gist describing options here: https://gist.github.com/annelo-msft/f8d8ca10484081e395df23f518de91cc Depending on the outcome of the design, the implementation may take more or less time.

@ArthurMa1978, can you help me understand your need to have it done in May? Is it different from the DPG GA goals?

[annelo-msft]

Per @KrzysztofCwalina, it is not required to produce a design prior to DPG v1.0 GA. Having considered multiple approaches to design, I believe that any of them can be made to work with design tradeoffs and that all the pieces are in place such that we can add operation rehydration without making breaking changes to the protocol methods on DPG libraries.

Right now, we return Operation or Operation<BinaryData> in the method signatures of methods that invoke long running operations. We don't expect to change this in the future. If we need to add subtypes of Operation specific to DPG to add functionality in the future, we will require rehydration of the operation or a downcast to the subtype to access that functionality.

[KrzysztofCwalina]

or we add this missing functionality to the base type. i.e. we convinced ourselves that we will be able to support it post v1