Re: [9fans] writing code

[Russ Cox <russcox@gmail.com>]

>         isochronous/streaming data transfer over 9p:
>
>                 9p is slow over wide area networks when streaming
>                 data, due to the ping-pong nature of the data
>                 transfer.  can anything be done to help solve this?

sure.  you could imagine adding a stream message to
start some number of reads, but maybe it's enough to
define that streaming style servers allow the client to
queue multiple read messages and respond in order.

you can already do that for file transfers by using the
offset field appropriately.

it's less clear what the kernel interface for streaming
would look like.

>         distributed authentication:
>
>                 the plan 9 authentication model relies on having an
>                 on-line authentication server.  as firewalls and
>                 mobile devices continue to proliferate, might it be
>                 worthwhile adding support for a peer-to-peer model be
>                 more appropriate?

i don't know what peer-to-peer means, but if we moved to
a public key model (which was the reason presotto created p9any)
and had the auth server just be a repository for public keys
(signed by bootes), then any amount of caching could happen.

>         graphics:
>
>                 high-bandwidth bitmap access is slow.  additionally,
>                 even the existing hardware acceleration could be
>                 leveraged more than it is (if any portion of a window
>                 is obscured, then no h/w acceleration is used for that
>                 window).  is it conceivable to have a system where all
>                 graphics operations are accelerated (as apple are
>                 apparently to be doing with their next system), or
>                 does the current architecture preclude this?

you don't need to accelerate everything, just the common stuff.
the obscured window case you describe is an important one
that should be handled better.  i'd love to see that happen.
it's not so much the lack of acceleration as the copying to
backing store and back.

i'm less excited by high-bandwidth bitmap access, but it still
shouldn't be hard.  rob took rio out of the loop for exactly this
reason -- talking to a local /dev/draw is just a single copy of the
data from user space to the frame buffer.  what's needed is a
driving application.

>         graphics primitives:
>
>                 graphics drawn with the existing non-bitblt primitives
>                 is not great (e.g.  lots of jaggies on diagonal
>                 lines).  could implementing subpixel rendering help
>                 matters here?

it should be straightforward to adapt the line drawing algorithm
to put down alpha-blended grey.  that would be nice.

>         how can i continue to do work when a server goes down?
>
>                 aan can deal with a broken network connection, but say
>                 someone reboots the fileserver?  is there any way we
>                 can incorporate some redundancy into the system, or
>                 make it easier for a applications to recover?

there have been at least two attempts to do this.  the early
brazil kernels maintained state in the Chans and tried to reestablish
them, but my understanding is that the code never really worked
right, and eventually it got taken out.  i wrote a user-level file
server for 9P1 that redialed as necessary to keep the connection
running without any help from the kernel.  it worked very well
but i never updated it for 9P2000.  it's not a big program.

russ