On Wed, Jan 5, 2011 at 6:51 AM, Pid <[email protected]> wrote: > On 1/4/11 11:05 PM, msacks wrote: >> The subject of modularity has come up previously >> (http://mail-archives.apache.org/mod_mbox/incubator-kitty-dev/201012.mbox/browser) >> and it seems to be a top issue going forward. >> I'd like to put out the following questions to the community for >> feedback to decide what is next up on the roadmap. >> >> Is changing the architecture of the code to support modularity the top >> priority? (My vote is yes) > > +1 > >> Is the base JMX functionality going to be a module (Client.groovy)? > > Not necessarily, we could provide the jmx connectivity & server > discovery stuff as a core component & make it available to modules.
I suppose the first thing we need is some loose sketch of how we want it to look, and then start coding to that model. > >> What functionality should a module have (Remote Methods, Pre-defined >> MBeans, Attach API, Groovy AST)? > > I think an overview of what it does now, and what we'd like it to do in > future (in general terms) will help inform the shape of the app & how we > divide it into tasks. So it sounds like we need a current functionality and a roadmap document? > > > p > >> What are the tasks required to achieve this end? (Which ultimately >> once discussed will be put into JIRA tasks) >> >> If theres anything I missed please feel free to contribute. >> >> Thanks, >> msacks > >
