Re: locking an int
- From: Peter Duniho <no.peted.spam@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 13 Oct 2009 09:47:58 -0700
Paul wrote:
lol moot not mute.....Absolutely right don't know what made me write it mute.
I agree as a communication protocol TCP is pretty much cross platform where I disagree is that re-inventing the wheel is a good thing. Most development languages have support for SOAP or even HTTP communication this day and age, even VB6 had SOAP support.
But you can't easily write a VB6 program that can receive SOAP-formatted data structures from a .NET program. The very thing that makes the .NET remoting technologies convenient to use -- built-in support for serialization/deserialization of .NET objects -- makes it very complicated to use those technologies with non-.NET peers.
Looking at the function in hand re-creating the wheel in this case has caused and always has the posibility of creating more issues than it solves. Extra testing and black box functionality with no standards for other consumers of the service to follow. Yes fine if you want to use it yourself but why then re-create something for additional dev and testing when you can find an existing standard that fits, lets be honest you will be hard pressed not to.
I have no idea what you're talking about. It's the use of the ..NET-specific features that may lead to "reinventing the wheel", as if the other end-point is not a .NET application, someone will have to reimplement the .NET protocol, in an environment where doing so it very difficult.
Contrast that to using some broadly supported format, like a simple null-terminated string, or even some simple XML. Even if using XML, in most environments there will already be support for plain XML, and of course null-terminated strings are ubiquitous. Neither requires any sort of special support for .NET types.
To me solutions like this are badly architected and waiting to fail, mabe im an old fart but when I see deveopers re-creating the wheel I alway qustion the design/architecture of the system. MS has spent a lot of time developing the remoting services in .NET and they are for the most part cross platform in the right hands and given correct architectural choices, why would you try to re-write this? Low level devices maybe but Software to Software?
I don't follow. In what way is .NET data serialization "for the most part cross platform"? Are you suggesting that I can easily (for example) write a Java or VB6 program that connects to and communicates with a .NET program that's using remoting or WCF? How will those programming environments represent the .NET data types embedded in the ..NET protocols?
Pete
.
- Follow-Ups:
- Re: locking an int
- From: Paul
- Re: locking an int
- References:
- locking an int
- From: Dan Holmes
- Re: locking an int
- From: Peter Duniho
- Re: locking an int
- From: Paul
- Re: locking an int
- From: Peter Duniho
- Re: locking an int
- From: Dan Holmes
- Re: locking an int
- From: Ben Voigt [C++ MVP]
- Re: locking an int
- From: Paul
- Re: locking an int
- From: Peter Duniho
- Re: locking an int
- From: Paul
- locking an int
- Prev by Date: Re: How would you do this?
- Next by Date: Re: How would you do this?
- Previous by thread: Re: locking an int
- Next by thread: Re: locking an int
- Index(es):
Relevant Pages
|
