db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanket Sharma" <sanketsha...@gmail.com>
Subject Re: Feature list for adding JMX extensions to derby
Date Thu, 08 Jun 2006 18:05:12 GMT
> 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"

> 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

> 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