The main two issues I had with HTTP/1.0 (both "fixed" now, except
that the fixes came too late to be ubiquitous in clients, servers,
and especially, proxies), were that the protocol did not provide
the *entire* URL to the server, specifically the server's full
domain name (fixed, somewhat hackily, with the HTTP/1.1 "Host:"
header), and the separate-TCP-connection-per-object ugliness
(fixed with HTTP/1.1's "Connection: Keep-Alive").

Besides those two, what other serious issues do you have with HTTP?

-Rob

Something else I thought of last night is that the people who design
mobile phone protocols are designing them for the hardware they want
to sell, not some hypothetical future hardware where the costs have
changed.  And bandwidth is *not* plentiful at present.  Only fools and
software people (have I specified more than one group of people
here?) think it's reasonable to try and sell a product which will
only work well using hardware no-one has yet.

(Actually, I *have* specified more than one group: software people are
obviously not fools because they *succeed* in selling these products.)

(In fact, if anyone has a 1st ed they don't want in the UK, mail me,
as I borrowed mine and the person who has it won't sell it to me...)

I will digress for a moment...

When I mentioned the spec IS-634 as an example that was difficult to
implement is because I actually had to do it.  This protocol is a
supervisory protocol, not the actual digital data stream that carries
the encoded voice.  The voice encoding protocols have to efficient and
thus TDMA can carry 3 or more digital voice channels in every analog
voice channel.  This is without a doubt necessary.  However the same
approach is taken with supervisory protocols to set up calls to the PSTN
(Public Service Telephone Network) and to do hand-offs and such. IS-634
travels over wires and is not the protocol between the cell phone and
the Base Station.  IS-634 was designed to hide that the call setup,
hand-off and other administrative stuff is actually AMPS, TDMA or CDMA.
It was designed to be layer to hide all of that.  Of course trying to be
all things to all people it became big and then they threw this
difficult definition for the PDUs.  I am not sure anyone actually
understood the spec, and there certainly was a lot of disagreement when
we asked for clarification on the protocol's state behavior from a MS
vendor.  I am not positive but the spec was about 500 pages (maybe more,
anyway one BIG binder).  At the time all I can remember is being peeved
about the complexity that I thought was unnecessary and that I found it
demoralizing.

Now to link this into Lisp...

One of the reasons I have decided that I will use Lisp is that my
perception is that there is less complexity, even though intellectually
I know this cannot be true.  By sticking with Lisp techniques, say in
designing a protocol with Lisp external syntax, I feel that I can
understand it better because it is expressed better.  Many times I find
myself translating a protocol or a computer algorithm into Lisp to
analyze its operation thoroughly.  Deep done I think by doing this I can
actually get to understand what the designer was _intending_.  Then I
can actually implement it because I know what needs to be accomplished.
Most of the time the thickness of the spec hides some very simple
points.

    Everyone going off and reinventing this stuff on their own, _even
    if they know they can do a better job of it_, when it is not the
    primary work they are involved in, AND WHEN THE AVAILABLE
    OFFERINGS WILL NOT NEGATIVELY IMPACT THIS PRIMARY WORK is just
    counter productive.  (emphasis added this time...)

You either didn't understand this part before or for some reason
actually believe that even with this piece considered the point made
still makes little to no sense.

/Jon

/Jon

I still think that the issues I mentioned are fairly valid in general,
but obviously this protocol could be just badly designed and you are
in a much better position to know that than I.

  I considered it a fairly unintelligent point to make.  It is a given
  that we do not set out to waste resources.  If you have to argue
  against people who do, that is certainly not my problem, but I find
  it oddly amusing to watch people who make such assumptions about
  others, as the only place this acquired stupidity can grow is where
  there is utter disregard for technical decisions.

| I believe my view of analyzing the tradeoffs of "build vs buy" in
| this area and makeing choices based on firm technical requirements
| and value added is exactly the correct way to proceed in such cases.

  Of course.  The interesting question is, however, what would make
  you change your mind, not what makes you convinced you are right.
  for all I know or care, you could be psychologically impelled to
  defend your choice and work hard to rationalize it after the fact.

| Perhaps a major difference here is that your business is not product
| centered/oriented, whereas ours is.

  Another fairly unintelligent point.  The question is which products,
  if this makes an interesting distinction, which I don't think it does.

  I think the explanation for our differences in view (and the reason
  you are not really listening) is that you seem to be venture capital
  funded, while we're making and spending our own money and can afford
  research that does not contribute to the first quarter bottom line.
  This is one of the reasons I'm working for a very solid company and
  have rejected golden-edged job offers from venture capital-funded
  pies in the sky.  I don't need bonuses or stock options to enjoy my
  work here, and I do see the hoping for that big cash hand-out as a
  huge misfeature where it is offered the employees.  I do not play
  the lottery or bet on horses, either.  We have a product that sells
  well, has significant growth potential, and I'm free to do whatever
  I think can contribute to that growth, including going away for a
  year to do weird stuff that they trust me implicitly to be good for
  the company, work on and with Common Lisp, etc.  Consequently, I
  find your attitude both condescending and ignorant at the same time.

  We live in a time when information technology is seen as magic by
  people who have only figured out that there is gold somewhere, but
  not how to find it or encourage anybody to find it.  I have extreme
  distaste for venture capital in such an ignorant climate.  If you
  are indeed venture capital-funded and have chosen CORBA because you
  think you'll avoid some expenditures tha would scare your investors
  and leave you stranded, I'd have to put your analysis in the "play
  it safe" category, rather than "play it intelligently, long range",
  and I am no longer impressed with your choice of CORBA and what you
  claim it does for you.

  Simply put: I have come to doubt that you have the resources to make
  intelligent choices, but have to make choices based on insufficient
  data and cannot afford to go wrong.  Instead of being able to afford
  to go wrong with your own money, a venture capitalist keeps a lot of
  people on a taut leash and while he can afford to go wrong quite
  often to make it big on a few, each of his "puppies" have to show
  early signs of success or be wasted.  This isn't _investment_ in my
  view, it's playing the lottery with other people's jobs and brains.
  Lotteries don't do it for me.  I find no thrill in accidents.

/Jon

Thank you, and thanks to Bruce and Erik as well.  I picked up
_Computer Architecture: A Quantitative Approach_ today (for about a
year now a local bookstore had one copy that no one buyed and which I
almost buyed several times already just because it looked interesting
but not knowing it's a classic (they also have a copy of the german
translation of SICP for more than a year now that, as well, no one's
buying)).

| (In fact, if anyone has a 1st ed they don't want in the UK, mail me,
| as I borrowed mine and the person who has it won't sell it to me...)

If you don't mind ordering it used and from the US, you should check
out www.abebooks.com, I took a look today and they have it for about
$20 or $30, IIRC.

Boris

--
bo...@uncommon-sense.net - <http://www.uncommon-sense.net/>

So they started out with 300 bps, and eventually got it up to 56K
bps.  Almost 200% increase.  Okay.  I agree that's impressive.

But what does this have to do with the original protocol?  It seems to
have more to do with the channel capacity, and maybe even how fast the
electronic interfaces were at different points along the chain.

Is the impressive part that, despite the massive increase in data
rate, that the same protocol is used, without breaking down with
timing issues, etc.?

Also, is it fair to say that they did a good job on an absolute scale?
For example, I think it's kinda hard to mess things up for a 300 bps
channel, depending on how noisy it is, but assuming a reasonable SNR.
Do they deserve to be commended just because they made it up to 56K
bps?  TCP/IP handles datarates of 10M bps, about the same factor over
56K bps as 56K bps is to 300 bps.

Judging protocols is hard business.  Protocols are often designed to
promise a certain amount of data integrity (usually very high).  If
one person designed a protocol that optimized the hell out of the
particular situation to acheive unbeatable performance, then should
his protocol be deemed better or worse than one which wasn't as
efficient, but when the channel specifications change (e.g. got
faster), didn't break down?

I think a lot of it has to do with what the optimization metric is.
It's probably not that much simpler to judge a protocol than to judge
a person's overall intelligence.  Or maybe it's just me.  There are
certainly a lot of criteria.

  I'd like to know what I have done to you to force you into that
  corner where all you can do is respond as if your worst-case
  scenarios for why people hold the opinions they do _must_ be true,
  without any room for doubt or alternatives.  If I have not done
  anything to you to force you into such a position, could you please
  get yourself out of that self-defensive corner and try to deal with
  people as if they aren't dangerous to you?  If you choose to spend
  your time defending yourself, I will take no part in it.

  What would happen if this discussion should prove that CORBA was a
  bad move for you?  What would happen if this discussion should prove
  that CORBA would have been a good choice for me?  Nothing, in either
  case, unless we decided _not_ to act on the new knowledge.  _That_
  would be illoyal to your employers.  Until then, acting out of fear
  that you might be proven wrong is what _is_ irrational.

  What _is_ clear to me now is that you have zero respect for other
  people and differing opinions regardless of how they arrived at
  them, but I attribute this to your need to engage in self-defense,
  which must be external to the discussion, so I'd just like you to be
  able to _listen_ to what people are telling you before you respond
  to them.  Until you have listened, there's no point in reading what
  you say in response, because I don't know what you respond to.

  Huh?  (/ (* 100 (- 56000 300)) 300) => 18566% increase in my book.

  I fail to understand why giving increases in percent makes sense
  when the factor of increase is greater than 2 (100% increase), but I
  notice people are talking about something that went from 1 to 10 as
  1000% increase, when it is clearly 900%, but they also call it a
  "ten-fold increase", which is correct.  Confusing multiplicative and
  additive increases is much too easy when computing with percentages.

| Is the impressive part that, despite the massive increase in data
| rate, that the same protocol is used, without breaking down with
| timing issues, etc.?

  The impressive part is their ability to make technology out of
  science.  I am one of those few people who are impressed by science
  and technology as such.  Most people seem to be more impressed by
  sports achievements and Harry Potter (either the books or the sales).

| Also, is it fair to say that they did a good job on an absolute
| scale?

  Yes.

| For example, I think it's kinda hard to mess things up for a 300 bps
| channel, depending on how noisy it is, but assuming a reasonable SNR.

  Yes, it _is_ kinda hard, but it _was_ pretty good when they did it.

| Do they deserve to be commended just because they made it up to 56K
| bps?

  They have "made it" it up to 10Mbps.

| TCP/IP handles datarates of 10M bps, about the same factor over 56K
| bps as 56K bps is to 300 bps.

  TCP is a transport protocol.  IP is a network protocol.  Modems do
  not transport or network, they simply move bits across a wire.
  Incidentally, TCP/IP works pretty well on gigabit networks, too,
  although the amount of data on a wire with a high bandwidth*latency
  product is _staggering_, which causes the window size in TCP to be a
  major problem if the connection is even slightly lossy.  Therefore,
  gigabit TCP introduces the same kinds of redundancy that the Telecom
  people added to their T3/E3 data link protocols (154Mbps) and above,
  and which have been used in comparatively low-bandwidth satellite
  communications for ages, namely a pretty good time distance between
  the data and its error recovery signalling that makes it possible to
  recover from outage stretches of up to 10 ms and sometimes more.

| Judging protocols is hard business.

  Yes, almost as hard as reading the specifications.

| Protocols are often designed to promise a certain amount of data
| integrity (usually very high).  If one person designed a protocol
| that optimized the hell out of the particular situation to acheive
| unbeatable performance, then should his protocol be deemed better or
| worse than one which wasn't as efficient, but when the channel
| specifications change (e.g. got faster), didn't break down?

  The funny thing about the real world is that you actually have to
  deploy _something_.  If you deploy, say, copper wire, with certain
  electrical characteristics all through your service area and there
  is solid international agreement on those characteristics, you know
  that you have deployed copper wire with those characteristics and
  you can tell your customers that they can buy telephones, modems,
  faxes, whatever, according to those specifications,.  We do not live
  in a world of magic (much TV and Harry Potter to the contrary), so
  those characteristics are not going to change until somebody goes
  out there and deployes some new cable at the cost of hundreds of
  billions of dollars.  This is why it is very good engineering and
  very intelligent use of the science and technologies available to
  manage DSL on the same kind of wire that used to carry 300 bps only
  20 years earlier.  I come from a family of engineers on both sides,
  and despite my university education, I _still_ think highly of the
  art of engineering, which is precisely that of managing to use the
  pre-existing physical conditions ever better and more accurately.
  Squeezing 56kbps out of a twisted copper wire laid 50 years ago in
  some cases indicates forethought and good engineering 50 years ago
  and good engineering today.  I take even more genuine pleasure in
  dealing with both the people and their work when such competence and
  caring is evident, than I do disdain and disgust when dealing with
  people who display incompetence and carelessness, such as on USENET.

| I think a lot of it has to do with what the optimization metric is.
| It's probably not that much simpler to judge a protocol than to
| judge a person's overall intelligence.  Or maybe it's just me.
| There are certainly a lot of criteria.

  How well you deal with the real world is a good criteria in both
  assessment processes if you ask me.  Getting lost in wishes for a
  world that is easier to live in warns _me_ of low intelligence.
  Judging what is done in the physical world according to what would
  have been great in a dream world is also a pretty good sign that
  someone is not firing on all plugs.  But I, too, work in software
  because the real world of physics and materials science is too hard
  for me to excel in.  That's part of why I'm easily impressed by the
  people who manage to keep the electricity grid of a whole city up
  and running while conditioning separately synced mega-volt feeds.
  On the other hand, it is probably because I try to understand the
  destructive forces of nature that I find this impressive.  Those who
  think nature is kind just because it is predictable have a hard time
  getting impressed with those who harness it and actually predict it.

Or gigabit Ethernet (1000BASE-SX or 1000BASE-T)??  Our systems do
over 650 Mbit/sec of TCP over GbE, user-mode to user-mode, with a
single TCP connection. [Over 800 Mbit/sec, if you allow "jumbo frames",
that is, 9000 byte MTUs, but that's non-standard.]

And 10 GbE is just about to pop out of the gate (already starting to
be demonstrated by a few vendors). But AFAIK there aren't any full-speed
host NIC interfaces for 10GbE yet, so for now the fastest TCP I know of
is still ours, at ~2.0 Gbit/sec (on a 6.4 Gbit/sec GSN link). [If we use
STP instead of TCP we can get ~6 Gbit/sec, user to user, single socket,
but we're talking about TCP, so I won't mention that further...]

+---------------
| Broadband ISDN (ATM) is even faster.
+---------------

Well, sure, all the way up to OC-192c/ATM, but there aren't very many
host NICs at that speed. On the other hadn, OC-12c/ATM NICs are fairly
common, and you can get ~500 Mbit/sec of TCP out of a well-tuned OC-12c/ATM
implementation, but I'm afraid GbE has already passed it by.

And at the higher speeds, people are dropping the ATM encapsulation and
just doing "packets over SONET" (POS). In fact, OC-192c/POS is even one
of the PHY/PMD options for the proposed 10GbE standard...

-Rob

    I have in no way suggested this, so I don't see the relevance.
    Certainly it has nothing to do with the given point, so it is
    unclear why you bring it up. This _looks_ for all the world like
    you are saying that "if you chose Corba, then _apriori_ you could
    not have done so as part of any analysis of the tecnical context
    and thus must be victimized by all these dysfunctional things".
    That kind of position is simply irrational.

As you can see I clearly stated that this _looks_ (with an implied "to
me", which I admit may not have been clear) like you are claiming that
any such choice is wrong apriori.  That doesn't say or in any way
imply that you were or are _actually_ saying this.  What I was and am
asking for was some clarity of your position on this with some sort of
_rationale_ for it.

I don't think that's asking for too much - do you?

/Jon

  Of course you are unclear on that, as you _still_ defend yourself.
  What makes you think I got it out what you _quote_ that you wrote?
  Why quote it?  To what end is that a rational course of action?  It
  is obviously rational in a self-defense position, but I have a hard
  time imagining any other rational explanations for this.

| I'm not defending _anything_, much less myself, or my choices.

  Jon, please.  You're doing it right there.  Just observe yourself.

| I would seriously consider how to go about changing to the proposed
| alternative.  I have already stated so in not so many words.  Why do
| have such a difficult time believing this?

  Because you reject everything I say before you understand it.  I'm
  sure you think you've been where I've been so you don't need to
  listen to what I say because you think you already know what I'm
  saying, but that is why I have taken this to a meta-discussion.  You
  need to stop thinking you know your opponent's position and you very
  much need to stop defending your own position and especially yourself
  -- otherwise you have no chance of _ever_ listening.  If you don't
  believe that this is evident in your behavior, at least _LISTEN_ to
  the fact that someone reads you that way.  Wonder why, at least,
  don't just reject it immediately because you don't understand it,
  which is exactly what you do with the technical questions, as well.

| > What would happen if this discussion should prove that CORBA would
| > have been a good choice for me?
|
| I don't know and I don't care.

  You really do have a hard time in general, don't you, not just with
  this discussion?  I was trying to strike a balance by asking that
  question both ways.  You seem to want this balance when you need to
  strike back, but when the balance is there, you reject it.  This is
  _not_ a good sign of mental health, Jon.  Stop defending yourself.
  You are _not_ under attack, OK?

| > What _is_ clear to me now is that you have zero respect for other
| > people and differing opinions regardless of how they arrived at them,
|
| Incorrect.

  It is _incorrect_ that that is clear to me?  *boggle*  How the fuck
  do you _know_ what is clear to me or not?  You _disagree_, Jon.  If
  you might begin to understand that your _disagreement_ in conclusion
  is something very different from terming somebody else's conclusions
  from all the available evidence to _them_ as "incorrect", you might
  have something to say worth listening to, but as long as you mix up
  _correctness_ with people's opinions and conclusions, you're just
  too stupid to waste any time on.  I'm trying very hard to make you
  understand that you do something here that tells me that what you
  have come to conclude is probably not trustworthy at all, and you
  _should_ take that as a sign that you need to do something different
  to increase that trustworthiness, not work very hard to desroy any
  remains of it.

| I think this is sound advice and clearly goes both ways.

  Your need to make it apply back to me is a very good indicator of a
  personality in need of defending itself, _especially_ when you
  reject when others hand you a "goes both ways" just a few paragraphs
  back.  Ask just about any shrink or psychologist about this if you
  have trouble understanding it.  I'm not going to elaborate, as you
  don't really _listen_ to what I tell you, no matter what I say.
  People who hold up a mirror and say "clearly goes both ways" have
  shut down the prerequisite brain activity to listen long ago.

| I respond to clearly stated positions that take into account all
| sides of an argument.

  Then you are clearly delusional, too, and your conclusions must be
  treated in accordance with such an assessment of your ability to
  observer yourself in action.  This doesn't make CORBA bad, it only
  means that your decision to use it is completely worthless as any
  form of testimony to its usefulness or the soundness of your choice.

| I don't think that's asking for too much - do you?

  I think if you didn't demand if others, but simply followed it, it
  would be perfectly OK.  As far as I know, I already comply, and you
  are not giving me any indication of _where_ I'm not, either, just
  this weak implication that I'm not, which just doesn't hold water.

  I'm through with you, Jon.  Let me know when you are willing to
  listen to what people who disagree with you are telling you.  I
  don't trust people who have made up their mind so hard it must be
  cracked before it can re-examine its path to its conclusions.

My main point was that it's hard to weight performance from
insensitivity to change in externalities.

I think that the best design is one which is fast enough to do the job
now, but personally I favor insensitivity to changes in other factors
more than a couple of percentage points on performance.

I feel the same way about general purpose programs.  Programs which
are massively optimized for what they do, but not easily extended are
a nightmare to work with.

It's just important to understand that if a someone's protocol breaks
down, it's not a symptom of poor design, if the specifications that
the designer was given ignored that in favor of squeezing every bit
out of the current external environment.  It's more a sign of poor
specifications than design.

/Jon