Guys,
Thanks for the feedback.
I did notice the wrapper actually. I started down the path described
for 2 reasons.
1. The whole usermaps.xml. SourceSafe is of course multi-user sensor
data. sensorshell.jar supports the current user (based on
sensor.props), and i couldn't find a way to override. Even if I could,
it would mean instantiating a process per user.
2. Lose the dependence on Java. Frankly, pure .NET folks are put off by
Java. Although, I don't find this to be a great reason, it is very
real. I would think that it's more of an issue for me though than it is
for the community at large.
I agree that IKVM is still early, and I certainly am concerned about
supporting issues arising from JDK incompatibilities. The most
promising information is that it's working (although on an albeit
limited test population). Another promising sample they have is that
Eclipse fully runs on IKVM. Plus, there is another open-source Java
initiative recently announced that may resolve our concerns around a
fully implemented JVM, and one never knows if Sun will actually
open-source Java.....stranger things have happened. IKVM does save us
(or anyone) from having to re-implement all the Hackystat functionality.
Cedric: I've thought about the whole rewrite possibility, and maybe that
will turn out to be the best approach. I'd just hate to embark on
something like that (and create duplicate code and maintenance issues)
if something like this works. Another approach is using J# which I've
had some experience with.
Maybe upgrading sensorshell.jar (and the wrapper) is the right
approach. Thoughts?
Btw, it is way cool to have something that references a library written
in Java and a COM DLL -- and it works.
Todd
Philip Johnson wrote:
--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
