home .. forth .. colorforth mail list archive ..

Re: [colorforth] TCP State Engine

Mark Slicker wrote:

Jonah Thomas wrote:



That was my claim.  I can believe a 3 block TCP, I have trouble
believing a full-feature 3-block graphical web-browser.



That was pulled from thin air at this moment. A full-featured 3-block
graphical browser is not mentioned anywhere.
I pulled it from thin air in my first post. I apologise for the confusion. 


If the C guys can do it in 4K of code (plus a few hundred bytes RAM
for one buffer, when you get a packet out of order you discard it and
ask them to resend it later) then likely you could do it in ColorForth
in 3 screens.



Just to note on code size: the code is compiled for an 8-bit processor.
Yes. It doesn't include 32-bit arithmetic for the 8-bit processor and there may be some other things missing that I haven't noticed. 


But the specs are tremendously complicated, and then
you also have to follow common practice.  If common practice doesn't
follow the specs you lose by following them.  And these guys say the
specs for communicating with other TCP/IP nodes are complicated, at
least for error conditions.  This particular implementation has more
than 300K of documentation and a significant fraction of it is
describing the complicated problem they're trying to solve.



There may be gains from examining common practice. If you can make
assumptions the specification would not allow you to do otherwise.



I'll give an example, by assuming a DNS server supports recurive queries,
you can make a very simple DNS resolver. I have done so.
Could be. And if common practice won't respond properly when you follow the spec, there's no point in following it. 


> =====================================================



> 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.



No, I say that if you *don't* need to support a full web browser you
can get by with just the part of TCP that you do need.  Maybe some
sort of UDP+.  If you *do* want a full web browser then you must
handle all the web pages that were designed for IE4.



Does IE4 require a special version of TCP?
No, but I expect it needs pretty much the whole thing. It's a web browser that would have to be special, not TCP. 


I figure web browsers have become kind of like commodities now, if it
doesn't do the standard things then people will only use it for things
commodity browsers don't do.



Would you the same about Operating Systems? How about languages? Should we
not drop what we are doing and use the commodity language C?
If you want to write code that will run on other people's OSes, then yes. You're looking for ways to avoid that, reasonably enough. If you want the mass of programmers to be able to read your code, you should write it in C. You don't need that. If you need to communicate with applications that can't handle dropped packets except with TCP, then you need TCP. So far the one example I've heard mentioned is web servers and web browsers. I expect you can make a fine tiny web server that commodity web browsers can interact with. I expect it's a big job to write a commodity web browser that will interact well with hundreds of billions of poorly-written web pages. If you want to display all those web pages the way final users would want them, then somebody has to do that big job. 


So again, it makes sense to
me to first go after other applications than a full-service web
browser, and it might make sense to start with applications that don't
demand all the capabilities that TCP provides.



No is discussing a "full-service web browser", and what do mean by "it
makes sense"? To promote Forth? What do the ANS people have to show for
last 20 years or so of standardization and commidization?
To get things that run for you. If you want to produce commodities you'll do better to define the standards yourself than meet other people's over-complex standards. Produce a black box that gets them results they want, where they don't have to know anything about how you did it. 


I think Forth could be a complete break through if people didn't try to
marginalize it in one way or another. Chuck as defined the axioms, where
do these axioms lead? I don't think anyone has fully explored the
implications of Forth.
Agreed, the sun will probably go out before we reach all the implications, even if we get the entire programming community doing it. 


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