gsoc2011 (java): split the appendix into another page

1 files changed, 85 insertions, 0 deletions

diff --git a/user/jkoenig/objcap.mdwn b/user/jkoenig/objcap.mdwn
new file mode 100644
index 00000000..e4cd20e8
--- /dev/null
+++ b/user/jkoenig/objcap.mdwn
@@ -0,0 +1,85 @@
+
+# Potential applications of object-capability languages
+
+The work discussed is this last part would have
+fewer immediate benefits for the Hurd project
+and has more of a research orientation.
+It is also unlikely that there would be any time remaining 
+to work on it at the end of the summer.
+(Though it could work as some kind of reward
+if I somehow managed to do a prefect job of all the rest
+within the allocated time :-) ).
+As a consequence,
+I don't really consider this a part of my application.
+
+This being said,
+to some extent the project discussed here
+will informed the way I design the Java bindings,
+since it depends on them
+and I intend to work on this at some point in the future.
+I also believe it touches on some interesting ideas,
+and a Summer of Code application is probably
+as good an occasion as any to discuss them.
+
+### Justification
+
+The primary advantage of multi-server operating systems is the ability to
+break what used to be the kernel into small pieces which can be isolated
+from each others. This makes sense from an engineering perspective, as
+smaller components can be swapped with different implementations and reduce
+the impact of bugs.
+A capability-based approach also ensures that the
+authority wielded by components is clear and reduced to the minimum required
+for them to function.
+These properties are crucial to the Hurd's agenda of user freedom,
+since in order to allow them to plug their own code into the system
+[FIXME: développer]
+
+However, this flexibility has a cost. In a system where the isolation of
+components relies on running them inside different address spaces,
+communication between them must be done through IPC calls.
+This introduces a trade-off between the size of the modules
+and performance as well as practicality,
+which imposes a limit to the granularity with which the system
+can be decomposed and the principle of least authority applied
+(to the code within a given process, a Mach port is ambient authority).
+
+Another issue is that of the threading structure of the system as a whole.
+In systems based on a monolithic kernel, user threads execute the kernel
+code themselves, which is then intrinsically concurrent. By contrast, in a
+system based on a “client-server” paradigm, each server must be explicitly
+multi-threaded if it is to serve requests concurrently. 
+
+### Object-capability languages
+
+An object-capability language is an object-oriented language which is
+restricted enough so that object references are themselves capabilities.
+
+One such language is Joe-E (FIXME: lien),
+which is an object-capability subset of Java:
+global state and static methods are mostly forbidden;
+careful white-listing of the objects and methods
+provided by the Java standard library
+ensures that compliant code cannot not access ambient autority.
+Ways in which object references can be transferred
+are restricted to the most obvious ones
+(for instance, exceptions are carefully restricted).
+
+As a result, untrusted Joe-E code can be executed without any further
+isolation and its autority can be controlled by carefully limiting the
+object references which are passed to it.
+This would allow to load and execute translators written in Joe-E
+in a single address space.
+
+### Bundling translators into a single process
+
+[mechanisme pour transmettre le code Joe-E
+et les port initiaux au serveur]
+[émulation des différentes tâches]
+
+### Challenges and further work
+
+[proof-carrying code / typed assembly,
+resource accounting (passer en revue la conception de Viengoos?)]
+
+