/cc @cpuguy83 WDYT?

Personally, I think it'd make sense to for Diff and ApplyDiff to deal with actual tar objects as opposed to the more abstract io.Reader... but that's wide open for discussion.

P.S - CI will fail until I rebase when #32 is merged (my bad)

@dave-tucker you can rebase cause I merged #32

@runcom 😎

Might be nice to have an implementation that just takes a graphdriver Init function and automatically maps the resulting graphdriver to the handler functions rather than everyone writing the same code.
So instead we'd ahve something like:

NewHandler(initFn graphdriver.InitFunc) *Handler

WDYT?

@cpuguy83 not sure I understand your comment... typical usage would be:

  d := MyGraphDriver{}
  h := graph.NewHandler(d)
  h.ServeUnix("root", "mygraph")

In this case, MyGraphDriver is anything that implements the Driver interface from this package.
We're taking care of the mapping from handler -> MyGraphDriver's functions

@dave-tucker This requires someone to write basiclaly a pass-through from the graphdriver itself to the plugin helper, whereas this code should be exactly the same for everyone.
If we take a graphdriver init func as above, we can just automatically map all calls directly to the graphdriver from the plugin helper instead of requiring someone to write this shim layer.

For instance, to test this out I started writing a shim like this:

type driver struct {
    vfs graphdriver.Driver
}

func (d *driver) Init(req *graph.InitRequest) error {
    fs, err := vfs.Init(req.Home, req.Opts, nil, nil)
    if err != nil {
        return err
    }
    d.vfs = graphdriver.NewNaiveDiffDriver(fs, nil, nil)
    return nil
}

func (d *driver) Create(req *graph.IDParentRequest) error {
    return d.vfs.Create(req.ID, req.Parent, "")
}

func (d *driver) Remove(req *graph.OperationRequest) error {
    return d.vfs.Remove(req.ID)
}

func (d *driver) Get(req *graph.GetRequest) (*graph.GetResponse, error) {
    dir, err := d.vfs.Get(req.ID, req.MountLabel)
    return &graph.GetResponse{Dir: dir}, err
}

But I think we can make it so people don't even have to write the shim.

@cpuguy83 ah i see! you're talking about existing, in-tree graphdrivers right?

@dave-tucker That's the example yes, but this would mean people can write a graphdriver as if they are in-tree, and not care about the plugin API layer.

@cpuguy83 got it. will try to find some time to hack on it within the next week or so

I have started working on the pass-through graph drivers (mentioning it to avoid duplicated efforts)

(I'll also rebase this PR)

@samoht awesome!

Closing in favor of #42