--On Wednesday, June 01, 2005 2:46 PM -1000 "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> wrote:
My personal view (this may not represent the entire Hackystat development group) is that both approaches are short-term. In the long term, I want to have a pure .Net sensorshell. It's not difficult to replicate the functionalities (soap communication, local off-line storage, strongly typed metric data from sdt xml), except that it takes some no-trivial effort. We never have had a strong demand for a pure .Net sensorshell, and I never have the time to work on this myself. If you have the demand from your client, and the resource meet the demand, I am glad to provide technical assistance.
It might be an interesting intellectual exercise to re-implement sensorshell in .NET using C#, but as a practical matter, why bother if we have a wrapper that does everything we need? In other words, why create a new system of several thousand lines of code that by definition must do exactly the same thing as another system of several thousand lines of code, and that will require us to maintain functional identity between the two code bases as they evolve over time? The only reason I can think of would be if for some reason an application context objected to the overhead of installing a Java JVM, or the small amount of additional memory the Java run-time requires, or the amount of additional processing time required for an invocation via wrapper. But these overheads have never been an issue before and becomes less likely to be an issue in the future. My personal view (and this clearly does not represent the entire Hackystat development group) is that the wrapper-based approach is a more-or-less optimal long-term solution. :-) :-) :-) Cheers, Philip
