* Re: [9fans] More 'Sam I am'
@ 2006-02-11 0:10 quanstro
2006-02-11 3:01 ` jmk
2006-02-11 6:04 ` ASN.1 (Was: [9fans] More 'Sam I am') lucio
0 siblings, 2 replies; 24+ messages in thread
From: quanstro @ 2006-02-11 0:10 UTC (permalink / raw)
To: 9fans
isn't this the "i don't trust new software" argument resurrected?
let's all install V7 from mag tape on our pdp-11s. ;-)
sorry. i couldn't resist.
- erik
On Fri Feb 10 16:54:45 CST 2006, lucio@proxima.alt.za wrote:
> > Would you pick
> > XML or ASN.1 if those were the only two options? If the pointy-haired
> > powers that be are mandating one or the other and, ``neither'' isn't in
> > the range of possible solutions?
>
> What are the alternatives? My pick is ASN.1, any time. You can call
> the ITU-T by as many ugly names as you like, but their standards are
> considerably more firm than more recent publications.
>
> ++L
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] More 'Sam I am' 2006-02-11 0:10 [9fans] More 'Sam I am' quanstro @ 2006-02-11 3:01 ` jmk 2006-02-11 14:29 ` [9fans] asn.1 alternatives Charles Forsyth 2006-02-11 6:04 ` ASN.1 (Was: [9fans] More 'Sam I am') lucio 1 sibling, 1 reply; 24+ messages in thread From: jmk @ 2006-02-11 3:01 UTC (permalink / raw) To: 9fans Many years ago now, a good friend of mine remarked that if we actually made all those whining about the state of things now compared to the "good old days" go back to using v7 Unix, they would quickly realise that times had actually moved forward and there were things they were used to that it didn't have and that they really needed. I used v[567] and I've ported v7, and I wouldn't go back. From what I understand, Plan 9 was an attempt to build on that by saying "this got us so far, but times are changing and it won't cut it with networks, bitmapped displays, SMP etc, we need a better base". That was a long time ago and no one has, to my limited non- computer science knowledge, attempted anything similar, they're all still working on copying 30 year old technology. I don't have an iPod, my mobile phone is 5 years old and I turn it on about 4 hours a week and there are many things about the 21st century that make me grumpy. But you can't go back. You should, however, be careful about how how you go forward. --jim On Fri Feb 10 19:12:00 EST 2006, quanstro@quanstro.net wrote: > isn't this the "i don't trust new software" argument resurrected? > let's all install V7 from mag tape on our pdp-11s. ;-) > > sorry. i couldn't resist. > > - erik > > On Fri Feb 10 16:54:45 CST 2006, lucio@proxima.alt.za wrote: > > > Would you pick > > > XML or ASN.1 if those were the only two options? If the pointy-haired > > > powers that be are mandating one or the other and, ``neither'' isn't in > > > the range of possible solutions? > > > > What are the alternatives? My pick is ASN.1, any time. You can call > > the ITU-T by as many ugly names as you like, but their standards are > > considerably more firm than more recent publications. > > > > ++L > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* [9fans] asn.1 alternatives 2006-02-11 3:01 ` jmk @ 2006-02-11 14:29 ` Charles Forsyth 2006-02-11 14:54 ` Sape Mullender ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Charles Forsyth @ 2006-02-11 14:29 UTC (permalink / raw) To: 9fans >> > What are the alternatives? My pick is ASN.1, any time. You can call >> > the ITU-T by as many ugly names as you like, but their standards are >> > considerably more firm than more recent publications. when i need to represent more than simple text or values, or attribute value pairs, which isn't all that often, more and more i use Rivest S-expressions, as i did on wednesday. they are unambiguous (unlike both ASN.1 and XML), easy to read and write, that can represent binary directly where that's appropriate, with an `advanced textual form' (like it!) that people can read without suffering eye strain, but with a well-defined canonical form (always helpful when comparing or signing things). i keep intending to try armstrong's ubf, but haven't, yet. it's perhaps more in the XML-RPC or ASN.1 realm. it has some good ideas, anyhow. simple text or values, or attribute value pairs are often adequate, require little code to read or write, and are often more efficient when all costs are taken into account. if you're lacking a `standard' for something you'd like to use, and you need that extra justification, just write an RFC, and then say ``i'm following an existing RFC''. on the other hand, if you're trying to talk certain existing protocols, you need some quantity of ASN.1; if you're trying to interpret certain existing data, you might need some XML. just remember, though, that no one needs `Web Services', the os/360 for the 21st century, and the upas tree of distributed systems. whenever it comes up, just hack round it, and even that is more than it deserves. also, in my experience, managers (pointy-head or not) are rarely overly caught up by the technical details. they just want such-and-such a problem to go away. they usually don't really care how you do it, especially if it works well and they never ever have to cut short a trip to the golf course because of it. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 14:29 ` [9fans] asn.1 alternatives Charles Forsyth @ 2006-02-11 14:54 ` Sape Mullender 2006-02-11 16:13 ` lucio 2006-02-11 16:57 ` Skip Tavakkolian 2006-02-11 16:05 ` lucio ` (2 subsequent siblings) 3 siblings, 2 replies; 24+ messages in thread From: Sape Mullender @ 2006-02-11 14:54 UTC (permalink / raw) To: 9fans >>> > What are the alternatives? My pick is ASN.1, any time. Ha. I'm working on a UMTS base station (another, interesting tale of hard real time in Plan 9) and we're using an ASN.1 compiler that typically takes 30-bytes ASN.1 packed messages and decompresses them into 5 megabyte (yes, MEGA byte) C structs. Amazing. In the defense of ASN.1 I must say that this is not so much caused by ASN.1 as by the incredible amount of configurational possibilities in UMTS connections (almost none of which are or will be implemented by anybody), and by the insistence of the comiler to code anything that has a known maximum length by a static array of that length. Sape ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 14:54 ` Sape Mullender @ 2006-02-11 16:13 ` lucio 2006-02-11 16:57 ` Skip Tavakkolian 1 sibling, 0 replies; 24+ messages in thread From: lucio @ 2006-02-11 16:13 UTC (permalink / raw) To: 9fans > and by the insistence of the comiler to code anything that > has a known maximum length by a static array of that length. I've never seen any of these mythical monsters, what do they really look like? Looking at the innumerable implementations of ASN.1 libraries, one is tempted to believe that enough effort has been deployed in that direction. Does any of the Open Source stuff (Heimdal, OpenLDAP, OpenSSL, rdesktop, to name but a few) actually ever re-use someone else's ASN.1 libraries? ++L ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 14:54 ` Sape Mullender 2006-02-11 16:13 ` lucio @ 2006-02-11 16:57 ` Skip Tavakkolian 1 sibling, 0 replies; 24+ messages in thread From: Skip Tavakkolian @ 2006-02-11 16:57 UTC (permalink / raw) To: 9fans i wonder if this is an entropy phenomenon. when an ABSTRACT notation is made CONCRETE, something has to give. it is as if instead of just translating a message in English to one in French, one sent a polyglot along with the message. >>>> > What are the alternatives? My pick is ASN.1, any time. > > Ha. I'm working on a UMTS base station (another, interesting tale > of hard real time in Plan 9) and we're using an ASN.1 compiler that > typically takes 30-bytes ASN.1 packed messages and decompresses > them into 5 megabyte (yes, MEGA byte) C structs. Amazing. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 14:29 ` [9fans] asn.1 alternatives Charles Forsyth 2006-02-11 14:54 ` Sape Mullender @ 2006-02-11 16:05 ` lucio 2006-02-11 17:52 ` Marina Brown 2006-02-11 16:28 ` Dan Cross 2006-02-20 0:04 ` Harri Haataja 3 siblings, 1 reply; 24+ messages in thread From: lucio @ 2006-02-11 16:05 UTC (permalink / raw) To: 9fans > also, in my experience, managers (pointy-head or not) are rarely overly > caught up by the technical details. they just want such-and-such a problem to go away. > they usually don't really care how you do it, especially if it works well > and they never ever have to cut short a trip to the golf course because of it. I don't share your luck and I think few do, although this forum may be more fortunate in that respect. I am heading to Cape Town tomorrow morning to install MS Exchange in what will probably still be a NetBSD shop for a year or so. Me, when I have no idea what Exchange actually look like! This is what comes of bucking the trend successfully. IT management there believe it will cost them less to entrust the installation to me than to bring in an MCSE (by whatever the current label may be) that will install herself permanently behind the Exchange keyboard at a formidable monthly salary. What will in fact happen, sadly, is that I'll be blamed for all the things that will go wrong with MS Exchange, irrespective of the real responsibility, more things will go wrong than usual because I'll insist in front-ending Exchange with the existing Sendmail installation, modified in haste to deliver to Exchange instead of the local mailboxes. All sorts of extremely fancy features of Exchange will be used and the reliability of the existing system will soon will be forgotten. My shoulders aren't wide enough to carry that load, but I can't afford to charge them what would be market related fees for my experience because it is not what they and their colleagues perceive to be the mainstream, so I'll have to sneak away from under their system very slowly and very surreptitiously as soon as I can find an alternative position. They will not, of course, discuss this, as they do not want to be encumbered with the necessary and unpleasant reality. Sigh! ++L PS: If you have a broad-spectrum position at Vitanuova that involves vision rather than productivity, I'm your man :-) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 16:05 ` lucio @ 2006-02-11 17:52 ` Marina Brown 0 siblings, 0 replies; 24+ messages in thread From: Marina Brown @ 2006-02-11 17:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs lucio@proxima.alt.za wrote: >>also, in my experience, managers (pointy-head or not) are rarely overly >>caught up by the technical details. they just want such-and-such a problem to go away. >>they usually don't really care how you do it, especially if it works well >>and they never ever have to cut short a trip to the golf course because of it. >> >> > >I don't share your luck and I think few do, although this forum may be >more fortunate in that respect. I am heading to Cape Town tomorrow >morning to install MS Exchange in what will probably still be a NetBSD >shop for a year or so. Me, when I have no idea what Exchange actually >look like! > >This is what comes of bucking the trend successfully. IT management >there believe it will cost them less to entrust the installation to me >than to bring in an MCSE (by whatever the current label may be) that >will install herself permanently behind the Exchange keyboard at a >formidable monthly salary. What will in fact happen, sadly, is that >I'll be blamed for all the things that will go wrong with MS Exchange, >irrespective of the real responsibility, more things will go wrong >than usual because I'll insist in front-ending Exchange with the >existing Sendmail installation, modified in haste to deliver to >Exchange instead of the local mailboxes. All sorts of extremely fancy >features of Exchange will be used and the reliability of the existing >system will soon will be forgotten. > > > Reminds me of last weekend - i got a paniced call from one of the sales execs - one with a clue - to get him OFF the exchange server because of the problems. Now he is happy to have his mail forwarded to a linux virtserver where he uses procmail and pine. I am ever so greatfull i am not responsible for the exchange. I warned them against it and they went with a hosted solution which gives people 150MB of mailbox space.... About the volume i dispose of after a long weekend. Good Luck... -- Marina Brown ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 14:29 ` [9fans] asn.1 alternatives Charles Forsyth 2006-02-11 14:54 ` Sape Mullender 2006-02-11 16:05 ` lucio @ 2006-02-11 16:28 ` Dan Cross 2006-02-11 16:53 ` Charles Forsyth 2006-02-11 22:47 ` Brantley Coile 2006-02-20 0:04 ` Harri Haataja 3 siblings, 2 replies; 24+ messages in thread From: Dan Cross @ 2006-02-11 16:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, Feb 11, 2006 at 02:29:19PM +0000, Charles Forsyth wrote: > also, in my experience, managers (pointy-head or not) are rarely overly > caught up by the technical details. they just want such-and-such a problem > to go away. they usually don't really care how you do it, especially if it > works well and they never ever have to cut short a trip to the golf course > because of it. 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 writing a Windows application. I probably don't have much ability to write it for another system (Unix, Plan 9, whatever) instead because I'd prefer that. As for ASN.1 alternatives.... When you have a choice, I would agree that S expressions are compelling. Another option is YAML, which is becoming popular in the scripting language world, and is fairly reasonable, even for representing complex hierarchical objects. - Dan C. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 16:28 ` Dan Cross @ 2006-02-11 16:53 ` Charles Forsyth 2006-02-11 22:47 ` Brantley Coile 1 sibling, 0 replies; 24+ messages in thread From: Charles Forsyth @ 2006-02-11 16:53 UTC (permalink / raw) To: 9fans > made for the implementation. An extreme example would be, say, if I were > writing a Windows application. I probably don't have much ability to write > it for another system (Unix, Plan 9, whatever) instead because I'd prefer > that. that isn't quite what i was suggesting (it was fairly carefully worded): in such a case you probably wouldn't have made `a problem go away', but rather introduced a new one because your solution was quite possibly fine but for a different environment. as a small concrete example, some of our grid users run existing Windows binaries for which source is unavailable, so the application does need to run on Windows (or perhaps a close emulation of it), and trying to convert it (say) to Limbo isn't particularly helpful; on the other hand, that still doesn't stop us using Inferno to build the grid infrastructure well and pleasantly (and without using XML or web services anywhere, as it happens), within the Windows environment. i wasn't suggesting one had carte blanche, just that it's often possible to find more freedom than one might initially expect in providing the solution; i also pointed out that anything off-beat might need to work really well to keep them happy [on the golf course] (but then, if it doesn't, why use it?) one point i didn't make, but ought to have done, is that it can be a little trickier when one is in competition for work, but even there it can be done. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 16:28 ` Dan Cross 2006-02-11 16:53 ` Charles Forsyth @ 2006-02-11 22:47 ` Brantley Coile 1 sibling, 0 replies; 24+ messages in thread From: Brantley Coile @ 2006-02-11 22:47 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives 2006-02-11 14:29 ` [9fans] asn.1 alternatives Charles Forsyth ` (2 preceding siblings ...) 2006-02-11 16:28 ` Dan Cross @ 2006-02-20 0:04 ` Harri Haataja 3 siblings, 0 replies; 24+ messages in thread From: Harri Haataja @ 2006-02-20 0:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, Feb 11, 2006 at 02:29:19PM +0000, Charles Forsyth wrote: > when i need to represent more than simple text or values, or attribute > value pairs, which isn't all that often, more and more i use Rivest > S-expressions, as i did on wednesday. > they are unambiguous (unlike both ASN.1 and XML), easy to read and > write, that can represent binary directly where that's appropriate, > with an `advanced textual form' (like it!) that people can read > without suffering eye strain, but with a well-defined canonical form > (always helpful when comparing or signing things). Sexprs would get my humble vote as well. BTW, re XML, there's also SXML that may or may not be interesting. http://okmij.org/ftp/Scheme/SXML.html -- The memory management on the PowerPC can be used to frighten small children. -- Linus Torvalds ^ permalink raw reply [flat|nested] 24+ messages in thread
* ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 0:10 [9fans] More 'Sam I am' quanstro 2006-02-11 3:01 ` jmk @ 2006-02-11 6:04 ` lucio 2006-02-11 6:54 ` geoff 2006-02-11 7:04 ` Skip Tavakkolian 1 sibling, 2 replies; 24+ messages in thread From: lucio @ 2006-02-11 6:04 UTC (permalink / raw) To: 9fans > isn't this the "i don't trust new software" argument resurrected? > let's all install V7 from mag tape on our pdp-11s. ;-) > > sorry. i couldn't resist. You're welcome, but I think you're off the mark. X.680 is less than 100 pages and is written in that peculiar jargon that CCITT/ITU-T have evolved to make sure that the real niggly faults are well hidden where they can only be discovered in the most painful fashion. Perhaps it is seriously flawed, but I have only a single paper by Carl Ellison entitled ASN.1 Misuse (September 15, 1995) to back that argument: "The ASN.1 standard (Abstract Syntax Notation 1) is proliferating, in spite of cries of anguish by computer professionals who are faced with implementing to those standards. The standard is flawed. Some of those flaws come from its complexity and ambiguity - a product most likely of having started down the wrong path and been subject to corrections by various interested parties along the way. It has acquired various warts and is apparently the result of a committee effort. Other flaws come from its misuse, and those are the one addressed in this paper." I note I'm missing pages 5 to 6 (of 6 :-). Thing is, XML is not 100 pages long, is nothing like less "complex or ambiguous" and is still work in progress. How much can one add to such a beast before its camel back breaks? And my question remains: "What is a better option for the conveying of platform-independent data than ASN.1 or XML?" ++L ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 6:04 ` ASN.1 (Was: [9fans] More 'Sam I am') lucio @ 2006-02-11 6:54 ` geoff 2006-02-11 8:06 ` lucio 2006-02-11 8:55 ` Steve Simon 2006-02-11 7:04 ` Skip Tavakkolian 1 sibling, 2 replies; 24+ messages in thread From: geoff @ 2006-02-11 6:54 UTC (permalink / raw) To: 9fans > "What is a better option for the conveying of platform-independent > data than ASN.1 or XML?" A somewhat-flippant answer would be text strings and numbers expressed as strings. But what ASN.1 (or BER) and XML seem to be trying to do is to permit the export and later import of essentially arbitrary C structs in a manner that will be portable across processor architectures. /sys/src/libsec/port/x509.c seems to be mostly concerned with ASN1 and it's 2,559 lines long, and that's short compared with the openssl ASN1 routines, which total 16,071 lines in my copy. So why not /lib/ndb format: textual attribute=value pairs with grouping? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 6:54 ` geoff @ 2006-02-11 8:06 ` lucio 2006-02-11 8:44 ` geoff 2006-02-11 8:55 ` Steve Simon 1 sibling, 1 reply; 24+ messages in thread From: lucio @ 2006-02-11 8:06 UTC (permalink / raw) To: 9fans > So why not /lib/ndb format: textual attribute=value pairs > with grouping? Because (a) they are language/alphabet specific and (b) they are inefficient. Before you jump down my throat, I am aware that the inefficiencies smack of premature optimisation, but in ASN.1 days they were mere failures of vision. And I do maintain that saving processor cycles and storage is not a futile quest. The corollary to Moore's Law is "Software bloat exceeds any gains in processor performance even before such gains can be exploited". It also strikes me as remarkable that you'd think ASN.1 is intended to represent C structures. I would think the intent was to be a message format on the wire and the internal representation was left as a matter of implementation. The latter, of course, is where it all fell apart because (a) there were issues that could not be finalised without conflict and (b) there were mistakes that were only discovered once different implementations could not interoperate. In the latter case, I have to concede that the IETF is better geared for the laying down of standards. Skip is right in that standards ought not to be accepted until there has been an implementation, but of course that sword has two edges, too. ++L ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 8:06 ` lucio @ 2006-02-11 8:44 ` geoff 2006-02-11 12:10 ` lucio 0 siblings, 1 reply; 24+ messages in thread From: geoff @ 2006-02-11 8:44 UTC (permalink / raw) To: 9fans Hmm, the old language-specific argument. The usual solution to this is to use a binary encoding, the theory being that by avoiding words, you avoid chauvinism. I'd still rather have a textual format, even if the attribute names have to be translated for speakers of other languages (they'd have to translate a binary encoding into their own language anyway). If we wanted to inconvenience everyone equally, the attribute names could be gibberish. I'm not convinced that the slight inefficiency matters, particular for a message format. We do build indices in /lib/ndb to speed searches, but that's for searching, not just encoding for transmission. If you're thinking of binary-decimal conversion overheads, one could insist upon using octal representation (as tar does), which can be converted more quickly than decimal, though that does make it a little less human-friendly. There has to be mapping between message format and something like a C struct (some internal representation). ASN.1 attempts to describe both, as I understand it, to facilitate conversion between the two. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 8:44 ` geoff @ 2006-02-11 12:10 ` lucio 0 siblings, 0 replies; 24+ messages in thread From: lucio @ 2006-02-11 12:10 UTC (permalink / raw) To: 9fans > If we wanted to inconvenience everyone equally, the > attribute names could be gibberish. > Or binary. Even your argument goes full circle. And because we're talking about information on the wire, why not stick to what the end points process best? Not that ASN.1 should be defended, but your argument needs its holes poked :-) > If > you're thinking of binary-decimal conversion overheads, one could > insist upon using octal representation (as tar does), which can be > converted more quickly than decimal, though that does make it a little > less human-friendly. > The human-friendly bit is a chimera, It's data on the wire, it was never the intent of CCITT (I presume) to treat it as anything else. Much as you can't detect the magnetic properties of core to decide what is in memory, you need some sort of translator to inspect the data on the wire. In CCITT terms, that isn't a problem as cost was never a consideration when investing in projects with 30- to 50-year life spans. It's the urgency of new technology that forces costs all the way down and deprives R&D departments of multi-digit budgets. > There has to be mapping between message format and something like a C > struct (some internal representation). ASN.1 attempts to describe > both, as I understand it, to facilitate conversion between the two. I'm not an ASN.1 guru, never will be. But I think ASN.1 is intended to be the permanent representation, with ephemeral internal formats as dictated by processing. I'm not sure where in the ITU-T recommendations I'd have to look to contradict you, however. It is perfectly possible for the ITU-T committee to have decided to intrude where they did not belong. They certainly mirrored the computer architectures of the time, with various predefined integer sizes as well as a variable length alternative, so they are guilty of parochial thinking. ++L ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 6:54 ` geoff 2006-02-11 8:06 ` lucio @ 2006-02-11 8:55 ` Steve Simon 2006-02-11 9:16 ` Bruce Ellis 1 sibling, 1 reply; 24+ messages in thread From: Steve Simon @ 2006-02-11 8:55 UTC (permalink / raw) To: 9fans > So why not /lib/ndb format: textual attribute=value pairs > with grouping? Vote 1 for Geoff. Seriously I tried this for a project, but got loads of flak for not using The Standard (XML) so when I "threw one away" last year I reworked the system using XML. To be honest the pain was short lived - writing the parser, and since then I don't see much difference. There are some of XMLs stranger rules and all those [<>/] which look a mess to my C trained eyes but I try not to look too often. (Before anyone jumps doen my throat I wrote a parser because I am on a small embedded system) -Steve ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 8:55 ` Steve Simon @ 2006-02-11 9:16 ` Bruce Ellis 0 siblings, 0 replies; 24+ messages in thread From: Bruce Ellis @ 2006-02-11 9:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I implemented both in ozinferno. ASN is almost ludicrous. XML was remarkably easy but ruthless. anyhow my XML parser does parse the XML spec (written in XML) and i'm yet to find a commercial product that does. brucee On 2/11/06, Steve Simon <steve@quintile.net> wrote: > > So why not /lib/ndb format: textual attribute=value pairs > > with grouping? > > Vote 1 for Geoff. > > Seriously I tried this for a project, but got loads of flak for not > using The Standard (XML) so when I "threw one away" last year I reworked > the system using XML. > > To be honest the pain was short lived - writing the parser, and since > then I don't see much difference. There are some of XMLs stranger rules > and all those [<>/] which look a mess to my C trained eyes but I try > not to look too often. > > (Before anyone jumps doen my throat I wrote a parser because I am on a > small embedded system) > > -Steve > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 6:04 ` ASN.1 (Was: [9fans] More 'Sam I am') lucio 2006-02-11 6:54 ` geoff @ 2006-02-11 7:04 ` Skip Tavakkolian 2006-02-11 7:09 ` geoff 1 sibling, 1 reply; 24+ messages in thread From: Skip Tavakkolian @ 2006-02-11 7:04 UTC (permalink / raw) To: 9fans i think any committee that comes up with a proposed standard should individually be responsible for implementing it. note that this would work for large or small efforts. if the committee is able to implement it and it works, then it would be adopted. specific to the question, i like the S-expression approach I've not used it for anything so my advice is as good as the random committee member. > And my question remains: "What is a better option for the conveying of > platform-independent data than ASN.1 or XML?" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 7:04 ` Skip Tavakkolian @ 2006-02-11 7:09 ` geoff 2006-02-11 7:53 ` lucio 2006-02-11 7:53 ` Skip Tavakkolian 0 siblings, 2 replies; 24+ messages in thread From: geoff @ 2006-02-11 7:09 UTC (permalink / raw) To: 9fans > i think any committee that comes up with a proposed standard should > individually be responsible for implementing it. That's not how PTTs do things! How do you think they came up with crap like OSI (X.400, X.500)? Sheesh, get real, kid! ☺ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 7:09 ` geoff @ 2006-02-11 7:53 ` lucio 2006-02-11 7:53 ` Skip Tavakkolian 1 sibling, 0 replies; 24+ messages in thread From: lucio @ 2006-02-11 7:53 UTC (permalink / raw) To: 9fans > That's not how PTTs do things! How do you think they came up with > crap like OSI (X.400, X.500)? Sheesh, get real, kid! ☺ Come, come, Geoff! They did precisely as they needed to. It probably has a lot in common with the urethra doubling back into the prostrate gland. Has anyone produced a better mouse trap yet? I note with horror that internationalisation is creeping into LDAP. ++L ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ASN.1 (Was: [9fans] More 'Sam I am') 2006-02-11 7:09 ` geoff 2006-02-11 7:53 ` lucio @ 2006-02-11 7:53 ` Skip Tavakkolian 1 sibling, 0 replies; 24+ messages in thread From: Skip Tavakkolian @ 2006-02-11 7:53 UTC (permalink / raw) To: 9fans >> i think any committee that comes up with a proposed standard should >> individually be responsible for implementing it. > > That's not how PTTs do things! How do you think they came up with > crap like OSI (X.400, X.500)? Sheesh, get real, kid! ☺ what i meant to say was "if i was philosopher-king in charge of the world i would make any committee ..." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [9fans] asn.1 alternatives
@ 2006-02-11 16:37 quanstro
0 siblings, 0 replies; 24+ messages in thread
From: quanstro @ 2006-02-11 16:37 UTC (permalink / raw)
To: 9fans
i've done this before. (but i wasn't responsible for the exchange half.)
it actually worked better than exchange-only because sendmail is
(was) much better at dealing with smtp mail.
- erik
On Sat Feb 11 10:24:28 CST 2006, lucio@proxima.alt.za wrote:
> than usual because I'll insist in front-ending Exchange with the
> existing Sendmail installation, modified in haste to deliver to
> Exchange instead of the local mailboxes. All sorts of extremely fancy
> features of Exchange will be used and the reliability of the existing
> system will soon will be forgotten.
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2006-02-20 0:04 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-11 0:10 [9fans] More 'Sam I am' quanstro 2006-02-11 3:01 ` jmk 2006-02-11 14:29 ` [9fans] asn.1 alternatives Charles Forsyth 2006-02-11 14:54 ` Sape Mullender 2006-02-11 16:13 ` lucio 2006-02-11 16:57 ` Skip Tavakkolian 2006-02-11 16:05 ` lucio 2006-02-11 17:52 ` Marina Brown 2006-02-11 16:28 ` Dan Cross 2006-02-11 16:53 ` Charles Forsyth 2006-02-11 22:47 ` Brantley Coile 2006-02-20 0:04 ` Harri Haataja 2006-02-11 6:04 ` ASN.1 (Was: [9fans] More 'Sam I am') lucio 2006-02-11 6:54 ` geoff 2006-02-11 8:06 ` lucio 2006-02-11 8:44 ` geoff 2006-02-11 12:10 ` lucio 2006-02-11 8:55 ` Steve Simon 2006-02-11 9:16 ` Bruce Ellis 2006-02-11 7:04 ` Skip Tavakkolian 2006-02-11 7:09 ` geoff 2006-02-11 7:53 ` lucio 2006-02-11 7:53 ` Skip Tavakkolian 2006-02-11 16:37 [9fans] asn.1 alternatives quanstro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).