Re: [colorforth] TCP State Engine
- Subject: Re: [colorforth] TCP State Engine
- From: "Samuel A. Falvo II" <kc5tja@xxxxxxxx>
- Date: Fri, 16 Apr 2004 09:42:50 -0700
On Friday 16 April 2004 08:46 am, Mark Slicker wrote:
> No one has talked about "refrigerator browsers". And yes I really do
> question why Sam is going into a lecture about letting go of
> assumptions. 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.
Claiming that I am trying to "convince myself" of this is like trying to
argue that Chuck is trying to "convince himself" that ColorForth is
simpler than traditional Forth systems. Let's be real here; I would not
be advocating my views if I did not already believe they were true.
I have no need for self-convincing. I'm already convinced. I've written
software that is highly modular. I've written software that is small,
and well-purposed. When working for Amiga, Inc., for instance, I've had
numerous reports that my software worked "too good," that it didn't have
"enough bugs" in it. (In this particular case, zero bugs.) I've
written software that can be combined in various ways, even ways the
original author (myself, in particular) have not imagined. My CUT 2.x
series of unit testing packages for C evolved this way. And now, once
Billy and I can get some free time, we're working on yet *another*
small, highly modular tool that "integrates" CUT, non-recursive
GNU/Make, and DARCS (all three of which will nonetheless remain separate
tools) into a sum which, by all our current indications based on our
experiences, is greater than the individual components alone might lead
you to think.
What relavence does this have to ColorForth? Not much, except to
illustrate that I'm not a complete ignoramous when it comes to software
development, its methodologies, or its philosophies, which you seem to
insist on harping on.
> I still reject the idea that all problems are trivial. I don't think
You took my writing way too literally. It was rather obvious from the
context that this is an idiomatic expression meaning, in this case, "We
aren't nearly as burdened by the details as our competitors are, because
we think about them *differently*, or *ignore them completely*;
therefore, our solutions to said `problem' are equally vastly simpler in
comparison."
And it's not just me who exercises the English language in this way.
Watch CM's fireside chats; he manages to nonchalantly dismiss many
problems, which you or I might consider overwhelmingly complex, as being
effortless to implement in, oh, say, a "small handful of screens." He's
not even *worried* about it.
My point was that if you let lose the basic assumptions that are
*commonly associated* with something, in this case that a "web browser"
is an all-inclusive monster that is fully capable of executing Flash
plug-ins, Java, Javascript, et. al., that the problem becomes very much
simpler.
And, frankly, grabbing an HTML page off an HTTP server *is* trivial.
OK, maybe the layout of said page is a little more difficult. I'll grant
you that. But compared to, say, Gecko, a Forth implementation *is*
trivial. Why? There is no need to build a complete, all-inclusive
Document Object Model implementation. It's not necessary (especially
since we are likely to ignore Javascript in its implementation) -- the
structure of the page is already contained in textual form. Forth is
fast enough that, when scrolling, one need only re-evaluate the HTML
page. And yes, I meant re-evaluate, because HTML tags, XML, or whatever
can be evaluated directly by building a special interpreter for them.
Unlike C or other related languages, Forth is excellent at building
"executable data structures."
I've found, as a general trend, that interpreting "complex" file types as
simple languages, where the reader for said file types is nothing more
than a really thin shimmy between Forth and the file itself, that
dealing with the file becomes trivial. Look at how big XML parsers for
C are, compared with the most simplest XML parsers for Forth. There's
no comparison. And I once implemented an XML parser, just powerful
enough for my needs, in a single block. That's *one* block for an XML
parser, trivially (yes, trivially) expanded to handle HTML. Oh, and
PLEASE don't get me started on those programs that *require* Lex and
Yacc to build their *configuration file* readers. Good lord.
If we treat a web browsing suite as a toolchain similar to compilers, we
get the following basic steps:
1. Fetch the source code for the page. This may involve reading file
off the local harddrive (e.g., if it's cached), or actual network
activity. The former case can actually be optimized right out by having
wget (for lack of a getter name) grab the web page and stuff it directly
into the cache.
2. "Compile" the HTML into a generic bytecode which the renderer can
scan through rapidly. Compile here is a bit of a misnomer. This could
be as simple as simply creating indices for the various objects in the
text file, such that the text file itself is unmodified. Such indices
would make re-scanning the text file lightning fast when, for example,
scrolling the display.
An alternative approach is to create a super-bitmap of the website
contents. This lets the compiler scan through the HTML file exactly
once, producing a "print out" if you will of the content. Oh,
shucky-darn! No animated GIFs! Boohoo. Like that's a seriously big
loss.
3. "Render" the HTML to the screen. This is the user interface part.
Note that the renderer as no clue what a network connection actually is.
This concentrates *solely* on display issues. It *assumes* the
"compiler" has produced valid output.
In the case of a superbitmap compiler, this renderer is exceptionally
trivial: it is merely block copies subsets of the bitmap to the frame
buffer in response to user scrolling input.
As you can see, taken *together*, these modules form 80% or more of a
traditional web browser as we know it today. The inter-module
interactions are largely linear. In fact, I can't think of any
exceptions. Taken individually, however, the components (a) are much
simpler, and relative to what is "out there" now, is trivial, and (b)
these components can all be re-used in other applications, again,
trivially.
> these things right is a very real challenge. If anyone disagrees, we
> should be seeing code from you very soon.
Your challenge is bogus, and an obvious (and childish) attempt at my
credibility; it does nothing to forward your views, but does affect your
credibility in a negative manner. I already explained that people pay
for my code, and that takes up much of my bandwidth, as does going to
school. It's also a logical fallacy, claiming indirectly that I don't
know what I'm talking about just because I have not contributed any
particular ColorForth code. All it proves is that I have not
contributed ColorForth code. And I don't intend to in the near future.
It speaks nothing of my, oh say, 20 year real-world software development
experience, my ability to design software, or my ability to see the
over-arching "big picture" (as managers love to call it).
> 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.
I also disagree with that CLF attitude. I wouldn't be here if I didn't.
The negation of that stereotype is precisely what I'm aiming for in my
Kestrel system, which while it won't be based on ColorForth, *will* have
Forth in ROM as its primary OS, and will be supported by me as a
Forth-running computer first and foremost. This includes Internet
access.
--
Samuel A. Falvo II
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com
