db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen" <John.Embret...@Sun.COM>
Subject Re: Feature list for adding JMX extensions to derby
Date Thu, 08 Jun 2006 15:32:48 GMT
Sanket Sharma wrote:
> Hi..
> 
> Please see the following and the attached file for a list of features
> that could be added to derby.
> 
> http://issues.apache.org/jira/browse/DERBY-1387
> 
> Awaiting responses

Just a couple of quick comments:

1)

<quote>
4. Assumptions and Dependencies

The interfaces follow the Apache coding style 
http://httpd.apache.org/dev/styleguide.html.
</quote>

The document you are referring to is C Language Style Guide, not Java. I 
just don't understand why, as there are several Java-specific coding 
guidelines out there. A couple of them are mentioned here:
http://wiki.apache.org/db-derby/DerbyContributorChecklist


2)

There is obviously a typo at:
"6.3 Remove vs. Local"


3)
I don't really understand what you are saying about JMX functionality 
and the Derby Network Server, but maybe that is because I don't know 
much about JMX...

Under "5.2.3 Network Server" you write

"The proposed extensions promise to deliver live monitoring of system 
along with the "regular" administration features found in most 
commercial database systems."

Then under "6.3 Remove vs. Local", you write in bullet 3.3:

"As a database server: Continuing what I said in (b) above, I think it 
is the responsibility of the server framework to expose this 
functionality to outside world, not the database engine."

(Minor thing: I think there is a typo here, I think you mean to refer to 
the nested 2), not b)). By "this functionality" I guess you mean remote 
access to monitoring and management features.

I guess what I don't understand is what role can/will the JMX extensions 
play in a pure "Network Server" configuration, i.e. Derby running as a 
stand-alone network server, where embedded access is a no-go?


4)

One final note, or rather a tip:

People are lazy (or, a nicer way to put it: People have limited time to 
spend reading other people's documents).

So, if you want as many people as possible to read your document(s), it 
might be wise to reduce the number of hoops they have to jump through in 
order to do so. I.e., I would recommend publishing relatively simple 
html documents "as is", so that people can view it using one click in 
their browser instead of the more cumbersome download-unzip-open 
procedure. If you really need CSS, perhaps you can embed it in your HTML?
Anyway, that was just a suggestion.


Thanks for working on this!


-- 
John


Mime
View raw message