GSoC (failed) application

libxdraw

My application to GSoC2009 could not be accepted (for reasons which are not important), but there were some interest on the project and I feel quite confident to give it a try in an unofficial way during the summer. After discussing my initial proposal with the mentors, this was my last comment on the GSoC web, and I think it explains quite well the aim of this project. I would also like to give thanks to all the organizators, for their comments and support during the application process and their effort.

Following rsc advice the original proposal has been modified. The draw device has been substituted by an standalone library, and instead of the wctl device a wsys server will be written. This is the new plan:

The first stage of the project (before the mid-term evaluation) will consist on writing a new (standalone) library, libxdraw. The idea is that this library is used by plan9-like draw devices in unix to speak to Xlib. Clients (p9p, 9vx, drawterm and Inferno) will call libxdraw, so they will not have to do any direct call to Xlib. However, they will be responsible of running libxdraw routines at their own: they can run them with kproc as kernel processes (9vx, drawterm, Inferno) or as unix commands (p9p devdraw). This way, changes to the clients should be minimal and localized:

On a second stage, a p9p wsys program will be writen. This program will run on unix and will serve a 9P wsys file system (built on p9p libdraw and 9pserve). This server could be mounted on 9vx/drawterm to open new (x)windows. p9p wsys would not provide a $wctl service or a cons device (and arguments to new when mounting will be ignored). On the other hand, it could be mounted with 'window -m' and run rio instances (but see below). From this point there are several possible paths:

The option to follow will depend on the results of the first month studying the existant code and the first stage of development.

Note on the wsys service: As discussed before a wsys service can be mounted with the 'window -m' command. However to run the 'window' command a $wctl file is needed. It is not convenient to launch processes directly from the p9p/kernel device. Instead, a $wctl pipe capable of executing 'window' commands can be obtained with simple rc functions (it will be rewriten in C, with error checking and without the need of dealing with 9vx awk system() command, but the concept is the same):

# bad awk system() in default 9vx distribution:
# fn wctl{ while () awk '$1=="new" { $1=""; if($2=="-cd") print "cd " $3; $2=$3=""; system("window -m" $0); }' }
fn wctl{ while ()awk '$1=="new" { $1=""; if($2=="-cd") print "cd " $3; $2=$3=""; print "window -m " $0 ; exit; }'|rc }
fn serv{ srvname=$1^.^$user;$1=/srv/^$srvname;shift;srv -e $"* $srvname }
fn riot{ serv riot wctl; wctltmp=$riot; riot=$wctl; wctl=$wctltmp; wctltmp=$riot }

After setting up wctl, the only missing piece for a window system is a cons device. As a workaround, rio can be run (or rio -i window). Further work could be possible, as mentioned above.

Goals of the project: