[Coco] CoCoNet wireless milestone

[Roger Taylor]

At 01:02 AM 3/30/2009, you wrote:
>On Mar 29, 2009, at 11:07 PM, Roger Taylor wrote:
>
>>As of tonight I'm thrilled to have the following working quite well
>>from the wireless bluetooth pak:
>
>Very neat, Roger. Question:
>
>>SAVER "http://www.somewhere.com/somefile.bar","COCOFILE.DAT",D  save
>>remote file as CoCo data file
>
>What is the reasoning behind the syntax? It seems different than the
>other modifications. I'd expect it to follow the normal SAVE(M) format
>and add parameters at the end, like:
>
>SAVE"FILE.TXT:1",A
>
>So :1 is the drive, A for ASCII, so I get having the ,x at the end,
>but why the URL first? Isn't that basically the "drive" in this case?



SAVER stands for Save Remote File (to a virtual disk).  I guess it 
should be called LOADR for Load Remote File, but there's no actual 
loading taking place.  The action taking place is a saving action 
(from a web server, to a CoCo disk) so I enhanced the SAVE command to 
support it.  If a handful of people can agree on a better way of 
doing this action then I'll be glad to change the command format for 
this particular function.

To best describe what SAVER currently does, it grabs a web page or 
file (binary supported), and quickly saves it to a mounted virtual 
disk.  Now every DOS command can access the local copy of the web 
file as usual.

DRIVE #,"pc path" lets you read or write to the remote PC .dsk image 
as usual.  DRIVE #,"web URL" grabs a temporary copy of the .dsk image 
and if you write to it, you're just writing to a temp copy, which 
lets programs run as usual but if you want to retain the disk you 
just BACKUP # to some_other_drive (physical or PC virtual disk).

There's still GET and PUT that can be reused as part of a Disk 
command, such as DRIVE GET, DRIVE PUT, or DRIVE LOAD, DRIVE SAVE, 
etc.  or even... SAVE DRIVE #   The first command needs to be an 
existing DOS command I can detour from and any tokens from BASIC, 
ECB, or DECB can be checked for after that, making it possible to 
chain commands together.

I think that DRIVE #, ON or DRIVE # ON should switch to a physical 
drive, but it appears that some other system out there does it the 
opposite from that.

-- 
Roger Taylor

http://www.wordofthedayonline.com