Re: [colorforth] TCP State Engine

[John Drake <jmdrake_98@xxxxxxxxx>]

--- Mark Slicker <maslicke@xxxxxxxxxxx> wrote:
> On Fri, 16 Apr 2004, John Drake wrote:
> >
> > Mark, I'm afraid you are the one that's lost sight
> > of the context here.  While I don't agree with
> > everything Sam says he's on the money this time.
> > At least if I understand him right.  Jonah was
> > the one saying (if I understood him right) that
> > somehow TCP would need to be more complicated
> > if you wanted to support a non-trivial browser.
> 
> He was speculating.

Jonah or Sam?
 
> > Sam's counterpoint is that the complexity of
> > TCP really has NOTHING to do with the complexity
> > of a web browser.  The same basic TCP protocol
> > that supported HTML 1.0 now supports HTML 4.0,
> > Flash, JavaScript, DHTML ect.
> 
> This is obvious. Did Jonas think that TCP and a web
> browser are the same
> thing? If so he is more clouded than I thought.

For clarity I'll repost that part of the
conversation:

=====================================================
> Thanks for reiterating the obvious. A Web Browser 
> is an example use of TCP, unless you want to create 
> a Forth web which I don't think can compete content 
> wise. A local Linux based proxy was once mentioned, 
> this is just shuffling the complexity elsewhere, 
> not solving the actual problem.
Sorry if it was too obvious.

The point is, if you want a web browser you have 
to be compatible with as much of the existing
complexity as you want to browse.  That isn't 
going to be any 3-block solution.  You might 
get TCP in 3 blocks, maybe, but you aren't going 
to get much of a web browser that way.
If the messages you want to send and receive 
over TCP are your own kind, then you can do 
it the way you want.  It won't compete with web 
browsers but it might be perfect for 
refrigerators and stoves and such 
to communicate over the net.  You might find 
a better way for a bunch of Motes to communicate than
what they have already.  There are lots 
of potential applications besides web browsers.  And
there's the question whether you need more than one
UDP packet at a time.  If you can put everything into
one UDP packet then you don't need to implement all of
TCP.  You still want to confirm that packets get 
through, but you don't need much packet reordering
etc.  So implementing just the part of TCP that you
need first might split the problem into easy pieces.
=====================================================

Now reading this I get the impression that Jonah
is saying that in order to support a full web
browser you would need to implement more then the
"part of TCP" that could be done in three blocks.
I feel that TCP is TCP.

> >
> > Now you asked Sam where he got his "5 block"
> > estimate for wget.  As you well know Chuck
> > has estimated 3 blocks for TCP.  I'm not sure
> > what Chuck is basing this on, but I'm guessing
> > it's on his experiences at iTV.  Obviously they
> > had a working TCP/IP stack that was written
> > in machineForth and/or ANS Forth.  (I'm not
> > sure who did what at iTV, I just know from
> > Jeff's stories that there were MF and AF
> > programmers).  So (correct me if I'm wrong
> > Sam) 5 blocks come from 3 block estimate for
> > TCP + 2 blocks estimate for the rest of wget.
> 
> Chuck says on his web site:
> 
> TCP/IP: 3 blocks?
> 
> That is where I get the number 3 for both TCP and
> IP. I have know idea how
> many blocks we'll need. 3 would be great, and I
> think it is something to
> shoot for.

Right.  You and Sam are in AGREEMENT so I don't
see your point of making an issue here.  Sam said
3 blocks for TCP then 2 more blocks for the rest
of wget.  2+3 = 5.  Forgive me for stating the
obvious, but I'm completely lost on why you're
making an issue over the obvious.
 
> > Also the following statement seems to have
> > gotten you off kilter.
> >
> > ===========================================
> > I couldn't agree more with this.  Fortunately for
> us,
> > most problems are quite trivial, as long as you
> let go
> > of certain basic assumptions and presuppositions
> > ===========================================
> >
> > You seem to be stuck on the idea that the "you"
> > in the above quote is "you" as in "Mark Slicker".
> > I think (again correct me if I'm wrong Sam) the
> > "you" is a generic for "anyone".  After all you
> > (Mark Slicker) are clearly not the one that was
> > talking about "refrigerator browsers".  The above
> > could be written as follows.
> 
> No one has talked about "refrigerator browsers". 

Jonah did.  See above.

> And
> yes I really do
> question why Sam is going into a lecture about
> letting go of assumptions.

Because he wasn't addressing his message only to
YOU!  I really question why you don't get this.

> Maybe he is the one with all these assumtions and he
> is convincing himself
> a browser doesn't need to be as complex as say
> Mozilla.

He's not the one who talked about "refrigerator
browsers".  Please read more carefully.
 
> I still reject the idea that all problems are
> trivial. I don't think the
> problems Chuck Moore solves are trivial. They may
> have a simple expression
> in code, but to achieve that expression is not
> trivial. I don't think TCP
> is trivial, and I don't a Browser is trivial. To get
> these things right
> is a very real challenge. If anyone disagrees, we
> should be seeing code
> from you very soon.

Fine.  Reject whatever you want.  But you are missing
the point.  It's not that "all problems are easy" but
that "most problems have been made far more 
complicated than they need to be".  The problems
that Chuck solves are not "trivial" but he solves
them in a comparitively "trivial" amount of code.
 
> Further, I reject the idea that is commonly spread
> in comp.lang.forth that
> Forth is only appropriate for "embedded systems", or
> systems with minimal
> resources.

Right.  But Sam wasn't embracing that idea.  Once
more read who mentioned "refrigerator browsers".
And to be fair to Jonah he didn't say that Forth
is only appropriate for "embedded systems" but he
seemed to imply that a TCP block that consisted of
only 3 screens would only be good for refrigerators,
stoves, motes i.e. embedded systems.
 
> >
> > ===============================================
> > Fortunately for us most problems are quite
> > trivial as long as the programmer can let go
> > of certain basic assumptions and presuppositions.
> > ===============================================
> >
> > Sam mentioned a few.  Here are a few more.
> 
> Please don't, unless these are personal hangups, and
> you wish to say how
> you found these assumptions are not well founded.
> 
> Mark

Mark, first of all nobody died and made you 
moderator, so you have no right to say 
"please don't"!

Second this is appropriate to the discussion
since Jonah said:
=============================================
You might get TCP in 3 blocks, maybe, but you 
aren't going to get much of a web browser 
that way.
=============================================

So some people might be interested in what 
does/does not define "much of a web browser".
If you don't want to hear this part of the
discussion then tune it out, because frankly
all you are adding is noise at this point.

Regards,

John M. Drake 



	
		
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com