Sketch: Registry plugins

Here's where we ended up with geard after going through the exact same discussion:

https://github.com/openshift/geard/blob/master/cmd/gear/darwin.go

Conditional go files that imported the packages then register them with a top level static.  

The alternative is just not to try to make plugins special and tell people if they want plugins they fork and recompile you in a way that reduces their merge cost.  I have to say that I tend towards the alternative in practical use, rather than trying to support dynamic plugin.  Making the standalone binary easy to wrap (like the things we added to master.go to make injection easier for OS) reduces the cost somewhat.

The docker plugin model isn't much better than rest plugins (calling another service for composition) in my opinion, and dynamic loading in Go seems to be even further out.

> On Nov 25, 2014, at 11:31 AM, Tim Hockin <notifications@github.com> wrote:
> 
> In pkg/registry/plugins.go:
> 
> > +type Plugin interface {
> > +	// Name returns the top-level REST name of this plugin, e.g.
> > +	// "replicationControllers".
> > +	Name() string
> > +
> > +	// Path is the desired path for this plugin within the backing
> > +	// store.
> > +	Path() string
> > +
> > +	// New instantiates the plugin into the provided backing store.
> > +	New(store Store) (apiserver.RESTStorage, error)
> > +}
> > +
> > +// All registered registries.
> > +var pluginsMutex sync.Mutex
> > +var pluginsMap = make(map[string]Plugin)
> Meh, it's pkg-private - how else are you going to do dynamic registration of plugins? Go doesn't let me mess with linker maps, so I can't iterate them on my own.
> 
> —
> Reply to this email directly or view it on GitHub.
>