db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Feature list for adding JMX extensions to derby
Date Thu, 08 Jun 2006 18:40:47 GMT
A note that it would be great if these discussions could be maintained 
as comments on the JIRA.

I think including Network Server specific features would be good to 
include in this document, I don't know why a separate document is 
needed.  There are a lot of valuable features that could be added there 
for monitoring and tuning not just the server but also the network 
channel between client and server.


Sanket Sharma wrote:
>> 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
> corrected. Thank you for pointing out!
>> 2)
>> There is obviously a typo at:
>> "6.3 Remove vs. Local"
> Corrected.
>> 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."
> What I wanted to say in (2) was these extensions will enable and
> facilitiate a server framework that might want to provide management
> and monitoring functionality. The server framework can simply expose
> the interfaces offered by proposed extensions instead of writing all
> the code. I have rephrased my thoughts and updated the document.
> Thank You!
>> (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.
> The sublist was initiall labelled as a,b and c. I overlooked it while 
> updating.
>> 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?
> These extensions will only *facilitate* such a server framework. In a
> pure Network Server configuration, the server will ultimately need to
> expose these interfaces and extensions. These extensions will provide
> statistics and data that is common across all three usages scenarios
> and concerns the core engine.
> The extensions do not target Network server in particular. I think any
> features specific for the Network server can be discussed in a
> separate document. Atleast, this is what I think. Your opinion is
> welcome.
>> 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.
> Okiedokie!! I have upload a plain html document.
> Thank You!
> Best Regards,
> Sanket Sharma

View raw message