From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9012f5c5ee963b63787c44482594c548@coraid.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] asn.1 alternatives From: Brantley Coile Date: Sat, 11 Feb 2006 17:47:59 -0500 In-Reply-To: <20060211162827.GR1620@augusta.math.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: fd53d2e4-ead0-11e9-9d60-3106f5b1d025 > I think, perhaps, that this is less true than it once was. In particular, > they need to answer to marketting and ensure that the product is sufficiently > buzzword compliant. But my point in bringing up the managerial team in the > first place was just to demonstrate that sometimes the person doing the > implementation doesn't *really* have all that much control over the choices > made for the implementation. An extreme example would be, say, if I were I find the most pressure on technical design to be one's peers. Entrenched technology carries a lot of weight. Pressure from co-workers to use the popular technology is also strong. A lot of it is just fashion; a lot is the `teach what industry wants, use what universities teach' cycle. Just look for every place you can strech things a bit. If you're talking to a SNMP client, you've got to use BER. If a web site is going to force XML at you, just do it. But when possible, from my experience, just use text. ASN1 reminds me of something that happened a few years ago. I ported V7 to an embedded application where my co-workers were developing the rest of the system on Sun4s. I warned them that my port was going to be 32 bit and that structure members would align to 4 bytes, not 2, as SunOS did in those days. They said that wasn't a problem, since they were marshalling the data into and out of the messages. Turns out that their marshalling code was full of structure alignment assumptions and they spend two weeks geting the library to work.