Host Side View (HSV) is exactly what the name indicates. It is the view of an AddIn from Host’s eyes. It is an abstract class usually defined by the Host. AddIn developers will implement all the functionalities and return result to the Host via HSV.

 

Paint.Net has a similar idea. It defines an abstract called Effect which other effect developer has to provide an implementation. Paint.Net treats all advanced Effects in the same way via a Render method. The AddIn model shares the same idea here. The HSV for Paint.Net can be as simple as below code.

 

namespace PaintDotNet.Effects

{

    public abstract class AddInHSV

    {

        public abstract void Render(EffectConfigToken parameters, RenderArgs dstArgs, RenderArgs srcArgs,

            Rectangle[] rois, int startIndex, int length);

    }

}

 

One question could be asked? If HSV model looks similar to Paint.Net’s current Effect model, do we really need a new AddIn model? This is a fair question. There are several benefits behind a unified AddIn model. I will come back to this topic many times. Here I will only share one. AddIn model provides many ways to activate an AddIn. AddIn activation API allows AddIn to be loaded in a separate AppDomain. This means AddIn can be unloaded if we don’t need it anymore. It also means that we can provide a security sandbox around AddIn if I don’t want AddIn to run unsafe code.

 

Having a separate AppDomain is cool. But it also comes with a cost. Many terms come into play once AppDomain gets involved like MarshalByRefObject, Serialization, Remoting etc.

 

Who is going to implement HSV and how are we going to handle cross-AppDomain calls? That is where we introduce our pipeline components.

 

Our next topic will be about HostAdapter and Contract.