gsoc2011 (java): improve the structure of the proposal

1 files changed, 41 insertions, 13 deletions

diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn
index d9617ab5..e8f7679b 100644
--- a/user/jkoenig/gsoc2011_proposal.mdwn
+++ b/user/jkoenig/gsoc2011_proposal.mdwn
@@ -146,6 +146,14 @@ which makes some packages fail to build on Hurd
      proposal). Porting Eclipse would be a good opportunity to test GCJ and
      OpenJDK.
 
+### Deliverables
+
+  * The glibc pthreads patch and any other fixes on the Hurd side
+    would be submitted upstream
+  * Patches against Debian source packages
+    required to make them build on Hurd would be submitted
+    to the [Debian bug tracking system](http://bugs.debian.org/).
+
 
 ## Create Java bindings for the Hurd interfaces
 
@@ -172,7 +180,33 @@ to begin experimenting with what makes Hurd unique
 without being faced right away with the complexity of
 low-level systems programming.
 
-### Approach
+### Tasks summary
+
+  * Implement Java bindings for Mach
+  * Implement a libports-like library for Java
+  * Modify MIG to output Java code
+  * Implement libfoofs-like Java libraries
+
+### Design principles
+
+The principles I would use to guide the design
+of these Java bindings would be the following ones:
+  * The system should be hooked into at a low level,
+    to ensure that Java is a "first class citizen"
+    as far as the access to the Hurd's interfaces is concerned.
+  * At the same time, the memory safety of Java should be maintained
+    and extended to Mach primitives such as port names and
+    out-of-line memory regions.
+  * Higher-level interfaces should be provided as well
+    in order to make translator development
+    as easy as possible.
+  * A minimum amount of JNI code (ie. C code) should be used.
+    Most of the system should be built using Java itself
+    on top of a few low-level primitives.
+  * Hurd objects would map to Java objects.
+  * Using the same interfaces,
+    objects corresponding to local ports would be accessed directly,
+    and remote objects would be accessed over IPC.
 
 One approach used previously to interface programming languages with the Hurd
 has been to create bindings for helper libraries such as libtrivfs. Instead,
@@ -186,17 +220,6 @@ However, once an initial implementation is done it would be easier to maintain
 in the long run and we would be able to provide Java bindings for a large
 percentage of the Hurd’s interfaces.
 
-### Design goals
-
-FIXME: a completer
-
-  * Give maximum flexibility to the Java code while maintaining the memory
-    safety of Java, and using a minimum amount of C code.
-  * Provide higher-level interfaces as well, ...
-  * Hurd objects would map to Java objects.
-  * Local objects can be accessed directly,
-    remote objects can be accessed transparently over IPC.
-
 ### Bindings for Mach system calls
 
 In this low-level approach, my intention is to enable Java code to use Mach
@@ -444,7 +467,12 @@ to implement the required ones.
 I would draw inspiration from libtrivfs and libnetfs
 to design and implement similar solutions for Java.
 
-### Packaging and long-term maintenance
+### Deliverables
+
+  * A hurd-java package would contain the Java code developped
+    in the context of this project.
+  * Modifications to MIG would be submitted upstream,
+    or a patched MIG package would be made available.
 
 The Java libraries resulting from this work,
 including any MIG support classes