avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geer, Christopher S" <christopher.s.g...@lmco.com>
Subject RE: What are .NET capabilities?
Date Thu, 31 Jul 2003 18:59:29 GMT

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, July 31, 2003 2:20 PM
> To: Avalon Developers List
> Subject: What are .NET capabilities?
> 
> Before we go down the road of developing Avalon.NET container and
> framework,
> I would like to find out how .NET handles certain things.  For
example, in
> Java we have JMX (Java Management Extensions) which *can* (though not
> necessarily) connect to SNMP consoles.

Microsoft has WMI which is based upon the DMTF's (www.dmtf.org) WBEM
proposal. In classic Microsoft fashion WMI is a proprietary version that
used DCOM so it's not very interoperable with much else. Secondly, .NET
has some serious bugs in it when it comes to WMI which are supposed to
be fixed by .NET 2.0

Personally, I tried to use WMI and hated it. I would like to see a JMX
type port honestly.

> 
> One of the things I would like us to answer is what is the fundamental
> difference between a .NET component and an Avalon component?  I can
answer
> questions all day about Avalon components, but I am sketchy on the
details
> of .NET components.
> 
> What management functions/instrumentation options does .NET provide?
For
> example, can we plug in to the Microsoft Management Console?

See above. Yes you can plug into the MMC however you can't write that
code in C# because MMC only has a COM interface. Someone did write a C#
wrapper however I'm not sure what the license for it is. I'll have to
dig it up. 

We tried to use that also, it's not bad but a little flakey.

> 
> What other .NET goodies would apply?

Well, I'm sure there are some things in there but there is also a lot we
will have to build. (i.e. Their collections aren't very robust. No
LinkedList, SortedMap...) We also have to decide how locked into
Microsoft we want to be. For example their System.Messaging API's are
pretty nice but are hard coded to only work with MSMQ.

Actually there are some good things such as the ease of building GUI's,
delegates can be nice in certain situations and Remoting isn't bad but
could still use some work. Obviously Attributes will come into play a
lot. If you want to do stuff with Web Services or GUI's C# is really
great.

I apologize if I sound down on C#, actually I do like it but at the
moment it's like working with Java 1.0. Hopefully others will have more
good features. All this said, I still need a container based on C# and
will do my part to help out. I'm just looking forward to .NET v2.0.

> 
> While some of these are long term (like management), others affect how
> much
> we want to simply use vs. invent.
> 
> --
> 
> "They that give up essential liberty to obtain a little temporary
safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message