[MIT-Scheme-devel] pclsr

[Matt Birkholz]

> From: address@hidden (Matt Birkholz)
> Date: Mon, 14 Mar 2011 22:09:45 -0700
> 
> > From: Taylor R Campbell <address@hidden>
> > Date: Mon, 14 Mar 2011 22:15:36 +0000
> > 
> > If I (open-output-file "/an/sshfs/on/a/distant/host"), Scheme spins.
> > This is frustrating.  (Edwin is still responsive, and I can still ^G
> > my way out of it, but Scheme never opens the file.)
> > 
> > [...]
> > 
> > Any ideas?
> 
> [...]  Don't use FUSE. [...]  Perhaps Gnome VFS?  [...]

If Unix's non-PCLSRing(?) operations are losing, why load them up with
all of the state of an encrypted channel?  Your problem may be the
same problem that caused GIO to avoid FUSE and go asynchronous.  Using
GnomeVFS directly keeps all that channel state on the near side of the
kernel.  I assume this keeps syscalls tiny little kernel pips --
little Transport Layer exchanges.

I took a stab at a GIO interface and now can read-line stuff like

        file:///etc/motd
or even
        http://yahoo.com/

I'm still looking at doing sftp://mumble...

I had to do a violence to generic-i/o performance, I'm afraid.  This
is asynchronous i/o, so the input-buffer-bytes cannot move during GCs.
I hacked genio.scm slightly to accommodate -bytes in an
external-string, but that means %substring-move! was replaced by
xsubstring-move!.  Too "generic"?

Is asynchronous i/o visible on our horizon?  We could address the
performance degradation by mallocing ALL input/output-buffer-bytes and
open-coding external-string-byte-ref/set! (like vector-8b-ref/set!?).

> OR
> 
> We write an ssh client that does all the directory caching and whatnot
> in sshfs, but in the modern, asynchronous way.  For extra trendiness,
> we could support WebDAV.

I see there is a popular ssh client for Java, Ganymed SSH2, that
"implements the SSH-2 protocol in pure Java".  That might be a
starting point for a Scheme implementation...