On Tue, Sep 23, 2014 at 5:57 AM, Tim St Clair <tstcl...@redhat.com> wrote:
> > > ----- Original Message ----- > > From: "Benjamin Hindman" <b...@eecs.berkeley.edu> > > To: "dev" <dev@mesos.apache.org> > > Sent: Tuesday, September 23, 2014 3:14:31 AM > > Subject: Re: Mesos Modules Design > > > > > > > > - create abstract classes to define interfaces to objects that should > be > > > modular > > > > > > > We're all in agreement here! > > > > - build modules as static libraries that can be assembled at link time to > > > create custom Mesos builds > > > > > > > Okay, but unless I'm missing something here we'll still need a level of > > indirection to wire everything together. What would that look like? > > > > Also, why ask an operator to go through the extra step of relinking > Mesos? > > Asking the operator to relink means they'll need a Mesos build > environment, > > while most folks will likely just have Mesos installed via an RPM (or > > similar). I'm not convinced that getting a link error will be a better > user > > experience then getting a runtime error that cleanly prints out something > > along the lines of "Version mismatch: the XXYYZZ module is not compatible > > with this version of Mesos". > > To ask service operators to re-link and possibly re-deploy mesos is a > non-starter imho. One of the goals of enabling "plugins" around key > interfaces is to avoid this type of operation. > ​What, concretely, does a service operator do if they have a bunch of modules that give runtime version errors? What are there options to get a running version? > > -- > Cheers, > Timothy St. Clair > Red Hat Inc. > -- Dominic Hamon | @mrdo | Twitter *There are no bad ideas; only good ideas that go horribly wrong.*
