[9fans] writing code

[rog@vitanuova.com]

> The mechanism is, and always is, someone writes code.

maybe this is unrealistic, but i'd like to see more "encouragement on
principle".  that is, if someone suggests something, it'd be nice if
people (particular labs or ex-labs people) would chip in and say "yes,
it's a good idea in principle; i'd like to see something like that"
(or perhaps "yes, but it should be done in this way", or "bad idea,
philosophically misguided").

if there were various projects around that had been given the
thumbs-up on principle (pending actual implementation), perhaps more
people might be inclined to get their hands dirty and write some code
towards those ends.

instead, i feel that people face the prospect of spending weeks
writing code, only to be told at the end that the whole aim of their
effort was misguided; or, worse, that the work was indeed misguided, but
it gets included anyway on the grounds of inclusiveness, diluting the
excellence of the whole system.

of course, it's perfectly possible to take the view that plan 9 is
perfect; that beyond minor bug fixes, new hardware ports and device
drivers and more applications, plan 9 is as good as it could be.

if that's the consensus view, then fine, i can live with that.

but personally, i think that there *are* places where plan 9 doesn't
perhaps do as well as it could, and fixing some of those might require
the rethinking of some core parts of the system.

maybe the first thing to do is to try and get some consensus as to
where the weaknesses of the system are.  the kind of things that might
be put in the BUGS section of intro(1), if there was one.

to start with, perhaps we could suggest areas in plan 9 which we think could use
some work, in the broadest terms possible, avoiding specific solutions;
then we could try to work towards specific projects aimed at addressing
those areas. people could give their views on each issue, e.g.

	a) this isn't a problem, it's meant to be this way.
	b) yes this is a problem; i've no idea what to do about it though.
	c) yes, this is a problem, but i don't think there's a decent solution possible.
	d) yes, this is a problem, and here's a possible solution.
	e) yes, this is a problem, but the right solution is too hard.
	f) you're coming at this from the wrong angle.
	g) you're making a mountain out of a molehill.
	h) i don't care in the slightest about this issue.
	i) i don't know what the hell you're on about.

here are a few for starters:

	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?

	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?

	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?

	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?

	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?