[ http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12415402 ]
David Van Couvering commented on DERBY-1387: -------------------------------------------- Hi, Sanket, thanks for a very nicely organized and formatted set of requirements! Here are my comments: - In Section 5.1 you are making the implicit assumption that the JMX functionality is targetted towards Derby being an enterprise-class database. I'm not sure if everyone would agree that's the sweet spot for Derby. If you look at the charter, the focus is on zero-administration, embeddability, standards-based, etc. That said, I think JMX is important (see "ease of use" and "standards-based"), but when looking at requirements I want to make sure we don't get too top-heavy... - You talk about two key areas that JMX can contribute to: monitoring and tuning. I would assume "tuning" includes general system configuration too. I can see all the existing Derby properties being exposed through a JMX interface. - Under proposed features, it would really help if each feature had its own unique identifier, like MON-1, MON-2, MAN-1, MAN-2, NOT-1, NOT-2, etc. - A well-thought-out and great list of features! There are a *lot* of features here. So, how to decide? Your separate table with priorities is one approach, but I'd like to propose something a little more interactive. I'd like the feature list section of the document to a Wiki page (or maybe it makes sense to migrate the entire document to Wik? - your call), and announce it on the derby-user and derby-dev lists. Each developers/user could add a column to the table and assign their priorities to each feature. This would be a chance for the community to get involved in picking which JMX features they'd like to see. If you do decide to stick with the current model, I highly recommend merging the priorities with the main feature table, so you are not constantly having to keep the two in synch, and so that readers don't have to keep switching back and forth between the two tables. - I'm a little confused about not providing remote access. Can you describe how an administrator who is not aJMX programmer can view, monitor, and tune an embedded Derby database that is not part of a larger application framework that provides JMX support? Whenever I talk to users, remote monitoring and administration are on the TOP of their list. I think this is required, but we do have to make sure we understand the security implications of such a topology. - A commonly missed aspect of requirements documents are non-functional requirements. These are "qualities" of the overall feature. Things like performance (response time, thorughput, number of concurrent users), security, ease of use, etc. - You had mentioned building our own JMX console. Is that still on the plate? Or do we just let existing JMX tools plug into our framework? > Add JMX extensions to Derby > --------------------------- > > Key: DERBY-1387 > URL: http://issues.apache.org/jira/browse/DERBY-1387 > Project: Derby > Type: New Feature > Reporter: Sanket Sharma > Assignee: Sanket Sharma > Attachments: Requirements for JMX Updated.html, Requirements for JMX.html, > Requirements for JMX.zip > > This is a draft proposal for adding JMX extensions to Derby as part of Google > Summer of Code project. I have identified and enlisted few features that > might be added to derby. The list is open for discussion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
