Using ASN.1's companion protocol, the Basic Encoding Rules (BER) to transfer XML would be a mistake! These lessons have already been learned and documented. Experience has shown that text based protocols and data streams are easier to decode, debug, understand, and process in programs. Look no further than the Simple Network Management Protocol (SNMP) which uses ASN.1/BER. How many hours/days of our lives did we spend debugging broken BER implementations. I'd much rather have my XML spend a few more microseconds on the wire that go through the BER exercise.
Ignore the rampant criticism that you'll see in here. There is life past C. Even if the language is trash, which I doubt, there may be some pearls in there that are worth learning. In the "old" days of computing, where we had many languages to choose from (APL/Lisp/Forth/Cybil (had to throw that in, sorry) Pilot/C/Fortran/Balm/Scheme), those of us that were interested could study and learn new things, ideas, ways of thinking. Sure, we all find comfort in our "cruise control" coding of strcpy(3) calls, but strive to look for new ways of doing things. And I don't mean reverting to Perl. I'm just glad some groups are innovating out there - my gcc wheels are digging a big rut in the road already.
Michael likes to peridiocally blame the downfall of Covad, Rhythms, and Northpoint on the imcumbent telcos. Damn, his rant is tiring. It's entertaining that when these companies had buckets of cash from their IPOs, and had their trophy CEOs, everyone was predicting the downfall of the RBOCs. Now when their lame business models fail, the telcos get fingered for the reason. These companies got extremely over-enthusiastic about the DSL demand, the price customer would pay, the much-hyped-but-never-proven "plug and play" installations and the optimistic hope of expanding the the copper loop limit past the usual 15Kft requirement. A lot of this optimism was fueled by vaporware from DSL product vendors, and in fact, a lot of these vendors put some serious cash into these carriers to pump them up even more. Oh yeah, the penny market DSL carriers also thought they roll out their services without building a customer service department that could spell "DSL", let alone assist with an installation problem.
Let it go, Michael.
Those terrible commie incumbents
on
DSL Woes
·
· Score: 1
I like the way the poster further hands off the blame on the incumbents. DSL is a difficult business, especially on the plant side with all of the copper uncertainties out here (bridge taps, coils, etc). A lot of these CLECs came in off their IPOs and thought they could quickly make a bucket of cash without a clue about the issues involved. Have you thought of blaming them for poor management? What about the crappy CLEC customer service? Shouldn't they have used some of their IPO money to staff people that could answer questions, rather than buy luxury boxes at sports arenas? The poster took the easy way out by poking the incumbents, but I believe that many of the problems were brought on by the CLECs and DSL ISPs themselves.
The reason that Qwest won't qualify you in Phoenix, but other providers will, is that Qwest Megabit does not currently offer a 144K service. 144K, also called, IDSL, is simply using ISDN technology to drive 144k (2B+D) without all of the ISDN junk attached. I am in exactly the same boat in Colorado - Qwest wouldn't qualify me, but Covad did. Covad is allright - only had one outage in the last three months, but it was a big one - 3/4 of a day due to a fiber cut somewhere. Oh yeah, and with 144K service, you can't share the line with voice like you can do with regular DSL.
I've heard that Qwest is coming out with a 144K service, in response to the other providers that are cleaning up at the low end.
Sorry but NTT has zero credibility in these types of announcements. They have great labs, world-class researchers, stunning prototypes, but have a less than stellar record in rolling these things out to the masses. Given the density of Japan's population, you'd think they could figure out a way to execute on these types of services and make some yen in the process.
Mozilla's C++ Coding Guidelines from 1998 at http://www.mozilla.org/hacking/portable-cpp.html advise against using C++ templates, exceptions, namespaces, and Run-time Type Information (RTTI) in order to meet their portability requirements. When can we expect that these features will be uniformly implemented across different platforms?
Slashdot Mirror
Using ASN.1's companion protocol, the Basic Encoding Rules (BER) to transfer XML would be a mistake! These lessons have already been learned and documented. Experience has shown that text based protocols and data streams are easier to decode, debug, understand, and process in programs. Look no further than the Simple Network Management Protocol (SNMP) which uses ASN.1/BER. How many hours/days of our lives did we spend debugging broken BER implementations. I'd much rather have my XML spend a few more microseconds on the wire that go through the BER exercise.
Ignore the rampant criticism that you'll see in here. There is life past C. Even if the language is trash, which I doubt, there may be some pearls in there that are worth learning. In the "old" days of computing, where we had many languages to choose from (APL/Lisp/Forth/Cybil (had to throw that in, sorry) Pilot/C/Fortran/Balm/Scheme), those of us that were interested could study and learn new things, ideas, ways of thinking. Sure, we all find comfort in our "cruise control" coding of strcpy(3) calls, but strive to look for new ways of doing things. And I don't mean reverting to Perl. I'm just glad some groups are innovating out there - my gcc wheels are digging a big rut in the road already.
Michael likes to peridiocally blame the downfall of Covad, Rhythms, and Northpoint on the imcumbent telcos. Damn, his rant is tiring. It's entertaining that when these companies had buckets of cash from their IPOs, and had their trophy CEOs, everyone was predicting the downfall of the RBOCs. Now when their lame business models fail, the telcos get fingered for the reason. These companies got extremely over-enthusiastic about the DSL demand, the price customer would pay, the much-hyped-but-never-proven "plug and play" installations and the optimistic hope of expanding the the copper loop limit past the usual 15Kft requirement. A lot of this optimism was fueled by vaporware from DSL product vendors, and in fact, a lot of these vendors put some serious cash into these carriers to pump them up even more. Oh yeah, the penny market DSL carriers also thought they roll out their services without building a customer service department that could spell "DSL", let alone assist with an installation problem.
Let it go, Michael.
I like the way the poster further hands off the blame on the incumbents. DSL is a difficult business, especially on the plant side with all of the copper uncertainties out here (bridge taps, coils, etc). A lot of these CLECs came in off their IPOs and thought they could quickly make a bucket of cash without a clue about the issues involved. Have you thought of blaming them for poor management? What about the crappy CLEC customer service? Shouldn't they have used some of their IPO money to staff people that could answer questions, rather than buy luxury boxes at sports arenas? The poster took the easy way out by poking the incumbents, but I believe that many of the problems were brought on by the CLECs and DSL ISPs themselves.
KT invented regular expressions. Where would we be without them? Hope he has a great second career - he deserves it!
The reason that Qwest won't qualify you in Phoenix, but other providers will, is that Qwest Megabit does not currently offer a 144K service. 144K, also called, IDSL, is simply using ISDN technology to drive 144k (2B+D) without all of the ISDN junk attached. I am in exactly the same boat in Colorado - Qwest wouldn't qualify me, but Covad did. Covad is allright - only had one outage in the last three months, but it was a big one - 3/4 of a day due to a fiber cut somewhere. Oh yeah, and with 144K service, you can't share the line with voice like you can do with regular DSL.
I've heard that Qwest is coming out with a 144K service, in response to the other providers that are cleaning up at the low end.
Sorry but NTT has zero credibility in these types of announcements. They have great labs, world-class researchers, stunning prototypes, but have a less than stellar record in rolling these things out to the masses. Given the density of Japan's population, you'd think they could figure out a way to execute on these types of services and make some yen in the process.
Mozilla's C++ Coding Guidelines from 1998 at http://www.mozilla.org/hacking/portable-cpp.html advise against using C++ templates, exceptions, namespaces, and Run-time Type Information (RTTI) in order to meet their portability requirements. When can we expect that these features will be uniformly implemented across different platforms?