[Color Computer] Re:[coco] www on coco

[Joel Ewy]

jdaggett at gate.net wrote:
> Curtis
>
> In my case I do not need the PPP layer. All I need is TCP/IP. My router and 
> firewall does PPPoE already and all I need to do is connect to the router DHCP 
> server to communicate to the internet. 
>
> It would be prudent to allow any COCO TCP/IP stack to obtain the IP address via 
> a DHCP server. 
>
> james ...
For this reason among others, any project like this should be
modularized.  A CoCo browser should be de-coupled from the network
component.  Whether the data comes via a TCP/IP file manager under
(Nitr)OS-9, a Superboard, a SitePlayer Telnet, sz/rz or DriveWire via a
helper PC proxy or slave CoCo, or arrives on floppy via sneakernet
shouldn't make a difference to the rendering engine.  The CoCo community
is too small and diverse to preclude anybody's contribution or
hardware.  It should be designed transport-agnostic from the outset, and
made in such a way that any of the above options could be used. 
Obviously some would be faster than others, and some would be easier to
implement.  But none should be prevented design.  If you have a fast
network connection, you should be able to use it, and at most have to
re-write or modify a module or two.  If you have an unconnected CoCo,
but want an off-line HTML reader, that should also be possible.  If
somebody can figure out how to make PPP work with a stock CoCo and a
Deluxe RS-232 Pak, that's great.  But if that's simply impossible, it
shouldn't have to stand in the way of all the other ways web pages might
get onto the CoCo.
How about something like this as a basic structure:

1:  HTML rendering subroutine module.  This should start off very
simple.  Just recognize a few basic HTML tags and convert them to
WindInt display codes.  There's already a Basic09 program that does this
much, I think.  Then it should learn to handle hyperlinks and inline
images.  The latter could be handled very simplistically, with the
presumption that the images have been pre-processed by helper modules
and saved as down-scaled, 16-color squashed VEFs or something like that.

2:  User Interface module.  Provide user menus and tie all the other
modules together.  Manage local caches, load and unload helper modules,
etc.  Reads a config file to find out what kinds of helpers it has
available and what their capabilities are.

3:  HTML pre-processor.  This divides long HTML pages up into more
easily digestible chunks with a file size boundary -- maybe 8K.  Inserts
a link to continuation pages.  This can run on the CoCo, on a slave
CoCo, or on a proxy PC.  Write it in C for maximum portability.  It
might package the HTML chunks into OS-9 data modules so they could be
loaded and unloaded from memory as needed.  It should also strip out
stuff like Javascript that will probably never be of any use on a CoCo.

4:  Image converter module(s).  Pre-scale images to fit a CoCo screen
and convert to CoCo-friendly file formats.  This could start out as a
stub that runs existing conversion utilities (NetPBM comes to mind) on a
helper machine.  A CoCo version would have to be highly optimized
assembly language and would optimize for speed over image quality by
default.  The UI module should provide the user with options for
re-displaying images of particular interest at higher quality and size. 
This code might run on emulators or FPGA Super-CoCos (CC-Five?) with
greater speed and better graphics than a stock CoCo 3, so there should
be a great deal of flexibility here.

5:  Network transport module.  URLs are passed to this module from the
UI module, and are interpreted in whatever way is available.  This
module will probably exist in various forms to handle a variety of
network hardware.  It could connect to a unix-like helper PC over a
serial connection, log in as a user, issue wget commands, and download
the resulting files with sz/rz.  Or it could use a
microcontroller/ethernet module with embedded TCP/IP stack to get
files.  On unconnected systems it might just bring up a file browser. 
In early stages it might incorporate the functions of the HTML
pre-processor and image converter modules, perhaps just by running
commands on a helper proxy machine.

By modularizing in this way the project becomes easier to envision,
easier to develop, easier to collaborate on, and it will become clear
which parts of the process the CoCo can actually do on its own.

JCE


>
> On 9 Nov 2006 at 13:08, L. Curtis Boyle wrote:
>
>   
>> On Thu, 09 Nov 2006 12:21:41 -0600, Tad Burnett <tburnett at vermontel.net>  
>> wrote:
>>
>>     
>>> Can you find an ISP that will talk to you using the slow baud and packet
>>> size...
>>> Are you willing to pay long distance charges
>>>  to reach it...
>>>
>>> How about the idea of using a PC at your location to serve as a link  
>>> between
>>> a DSL internet and a CoCo ..
>>> PC could also be used as a mass storage device to connect to a plane Jane
>>> CoCo through the tape drive port...
>>>
>>> Instead of hard ware changes to the CoCo that only a few would try
>>> software could be written and shared by many....
>>> Tad
>>>
>>>       
>>      That's not a bad idea, although I am suprised that one would need long  
>> distance to contact a modem based ISP... here in Canada, pretty well all  
>> ISP's have both (especially for rural areas, where you can't get  
>> broadband).
>>      I know Mark's Superboard is supposed to have a TCP/IP hardware chip on  
>> it that handles the packet handling, so that would make things much easier  
>> (I believe it even includes the outside PPP layer as well), as well as  
>> some of the protocols within TCP/IP (FTP, etc.), but that would only  
>> appeal to the hardcore hackers who don't mind soldering inside of their  
>> machines (I would have to get someone to do that for me... my soldering  
>> skills suck).
>>     The only problem with hosting on a local PC is that one would have to  
>> make it cross platform to cover all of the Coco users who also have a  
>> "main" PC... you would have to write for Windows, Linux and OS X.
>>      The other thing is that since Contiki is on a C-64 (an inferior  
>> machine to a Coco 3), and they did it, is that there is the challenge of  
>> getting it to work on a Coco... which is the reason a lot of us did a lot  
>> of the stuff for the Coco and OS9 over the last 2 decades.
>>
>> -- 
>> L. Curtis Boyle
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> -- 
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.409 / Virus Database: 268.14.0/525 - Release Date: 11/9/2006
>>
>>     
>
>
>
>