[Coco] DriveWire netdisk interface

[Aaron Wolfe]

I did a few tests with fusedav and apache just now.  Seems to work
pretty OK just to mount a DAV share in your local filesystem, then use
regular DriveWire to give an image on that share to the CoCo.  Maybe
some excessive read/writes (and the entire disk image each time),  and
had a couple weird things happen, but probably more of issues with
fusedav, apache, or just the way DriveWire talks to the local disk.
Probably could be optimized.

So.. as it turns out, there is really no point in having netdisk,
since you can just do this with exisiting tools :)

It would be nice to have a public repo of disk images accessible via
webdav, though.

-Aaron



On Thu, Nov 19, 2009 at 5:15 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Thu, Nov 19, 2009 at 3:09 PM, John W. Linville
> <linville at tuxdriver.com> wrote:
>> On Thu, Nov 19, 2009 at 02:19:24PM -0500, Aaron Wolfe wrote:
>>
>>> I wanted to use webdav, but as far as I could tell, webdav doesn't
>>> support reading or writing specific portions of a file.  If i'm wrong
>>> about that please let me know!
>>
>> Hmmm, I wasn't aware of that -- FWIW I'm more of a kernel guy...
>>
>>> To implement a disk image that "just works" with DECB and OS-9,
>>> we have to be able to read and write abitrary 256 byte sections of
>>> the file.  I wrote my own simple protocol for this because i didnt
>>> see any way to do this with http.
>>
>> Well, I do appreciate that those semantics exist between the CoCo
>> and the DW server.  But I don't think those semantics really need to
>> exist between the DW server and the backing store.  In fact, those
>> semantics would seem to decrease overall performance and increase the
>> chance of disk image corruption in the event of a failure.
>>
>> I guess what I was thinking is that you would use a pull/modify/push
>> model, where the pull would occur when the DW server "mounted" the
>> image and the push would occur when a dirty image was "unmounted".
>> If the webdav server is worth it's salt, that should at least ensure
>> that so long as the DW server didn't push a corrupted image then the
>> webdav server images should always be correct.
>>
>
> I had thought about this model.  webdav would certainly support
> transfering entire images back and forth, and using webdav would make
> lots of other things work nicely.
>
> the only drawback I see is that changes written to the disk are lost
> unless the "unmount" process is completed.  this requires the user to
> take an extra step in the drivewire server, makes netdisks work a
> little differently than regular disk images.  this is why I went with
> the original design.  however, webdav does have some compelling
> advantages and probably is a better way to do things.  I will look at
> adapting to this model.
>
>
>> Now, pull/modify/push could slow down the mount/unmount process,
>> but realistically how big are those Internet-based CoCo disk images
>> going to be? :-)
>
> depending on the internet connection, might be almost no delay, or
> maybe up to a minute or so, i doubt it's too much of an issue.  means
> some additional logic in the DW server since disks are not immediately
> available once selected like they are now.
>
> overall, using webdav is probably the right way to do it.
>
>>
>> John
>>
>> P.S.  Again, I'm just trying to wise and helpful. :-)  Don't let me
>> discourage if you don't like my advice!
>> --
>> John W. Linville                Someday the world will need a hero, and you
>> linville at tuxdriver.com                  might be all we have.  Be ready.
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>