I'm sorry, but I'm still having a hard time understanding why this needs to be dynamic.
If the mesos core is split into modules that are built as standalone libraries (static) then at link time the right combination of libraries can be bundled together to create the end result. If you want to get even smarter, we can have default versions that are linked in to the mesos core as weak symbols so later linked libraries can override the defaults. This may mean that we move to static linking across the board, but frankly there are a few benefits to that approach. With the approach as defined, does this mean that the default versions will also have to be reimplemented as modules? Has any effort been put into determining the performance overhead of the approach as specified? On Fri, Sep 19, 2014 at 11:35 AM, Niklas Nielsen <nik...@mesosphere.io> wrote: > Hi everyone, > > We have been iterating on a design for pluggable modules in Mesos lately > and wanted to get a last round of feedback before putting out patch sets. > > Tim St Clair, Ben Hindman and I started the discussion (and work) on this > subsystem https://issues.apache.org/jira/browse/MESOS-1224 and > https://issues.apache.org/jira/browse/MESOS-1384. > Kapil and Bernd took over the work (shepherded by Ben H and I) and have > expanded on the original design to cope with api/modules/mesos versioning > semantics and be extensible enough to cope future changes in the modules > subsystem (dealing with modules dependencies, etc). > > The latest description of the modules system has been captured in: > > https://cwiki.apache.org/confluence/display/MESOS/DRAFT+Design+Doc+-+Mesos+Modules > (for those of you who don't want to read through the JIRA threads). > > We have an implementation ready based on this design and will be sharing / > starting review rounds start next week. > > Feel free to use this thread if you have any questions. > > Cheers, > Niklas > -- Dominic Hamon | @mrdo | Twitter *There are no bad ideas; only good ideas that go horribly wrong.*
