user/jkoenig: reorganize

1 files changed, 0 insertions, 180 deletions

diff --git a/user/jkoenig/gsoc2011_proposal/discussion.mdwn b/user/jkoenig/gsoc2011_proposal/discussion.mdwn
deleted file mode 100644
index 0131d8d5..00000000
--- a/user/jkoenig/gsoc2011_proposal/discussion.mdwn
+++ /dev/null
@@ -1,180 +0,0 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-Some [[tschwinge]] comments regarding your proposal.  Which is very good, if I
-may say so again!  :-)
-
-Of course, everyone is invited to contribute here!
-
-I want to give the following methodology a try, instead of only having
-email/IRC discussions -- for the latter are again and again showing a tendency
-to be dumped and deposited into their respective archives, and be forgotten
-there.  Of course, email/IRC discussions have their usefulness too, so we're
-not going to replace them totally.  For example, for conducting discussions
-with a bunch of people (who may not even be following these pages here), email
-(or, as applicable, the even more interactive IRC) will still be the medium of
-choice.  (And then, the executive summary should be posted here, or
-incorporated into your proposal.)
-
-Also, if you disagree with this suggested procedure right away, or at some
-later point begin to feel that this thing doesn't work out, or simply takes too
-much time (I don't think so: writing emails takes time, too), just say so, and
-we can reconsider.
-
-Of course, as this wiki is a passive medium rather than an active one as IRC
-and email are, it is fine to send notices like: *I have updated the wiki page,
-please have a look*.
-
-One idea is that your proposal evolves alongside with the ongoing work, and
-represents (in more or less detail) what has been done and what will be done.
-Also, we can hopefully use parts of it for documentation purposes, or as
-recipes for similar work (enabling other programming languages on the Hurd, for
-example).
-
-For this, I suggest the following procedure: as applicable, you can either
-address any comments in here (for example, if they're wrong :-), or if they
-require further discussion; think: *email discussion*), or you can address them
-directly in your propoal and remove the comments from here at the same time
-(think: *bug fix*).
-
-Generally, you can assume that for things I didn't comment on (within some
-reasonable timeframe/upon asking me again) that I'm fine with them.  Otherwise,
-I might say: *I don't like this as is, but I'll need more time to think about
-it.*
-
-There is also a possibility that parts of your proposal will be split off; in
-cases where we think they're valuable to follow, but not at this time.  (As you
-know, your proposal is not really a trivial one, so it may just be too much for
-one person's summer.)  Such bits could be moved to [[open_issues]] pages,
-either new ones or existing ones, as applicable.
-
-
-# POSIX Threads Signal Semantics
-
-  * Great!  [[tschwinge]] had a brief look, and should have a deeper one.
-
-  * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this
-    (that is, only the refactoring patches for starters?) on the buildds.
-
-  * Then: should ask Roland to review.
-
-  * Documentations bits should probably be moved to [[glibc/signal]].
-
-
-## libthreads (cthreads) Integration
-
-  * [[tschwinge]] suggests to leave them as-is?
-
-
-## [[libpthread]] integration
-
-  * To be done.
-
-
-# Java
-
-  * [[tschwinge]] has to read about RMI and CORBA.
-
-
-# Joe-E
-
-  * For later.
-
-
-# GCJ
-
-  * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly
-    dead?  (True?)
-
-  * Thus perhaps not too much effort should be spent with it.
-
-    If the POSIX threads signal semantics makes it going, then great, otherwise
-    we should get a feeling what else is missing.
-
-
-# OpenJDK
-
-  * All in all, [[tschwinge]] has the feeling that a working OpenJDK will be
-    more useful/powerful than GCJ.
-
-  * We need to get a feeling how difficult such an OS port will be.
-
-  * [[jkoenig]] suggests OpenJDK 6 -- should we directly go for version 7
-    instead?
-
-      * What are the differences (regarding the OS port) between the two
-        versions?  Or this there something even more recent to be worked upon,
-        for new OS ports?
-
-          * Perhaps the different versions' OS port specific stuff is not at
-            all very different, so that both v6 and v7 could be done?
-
-  * They seem to have a rather heavy-weight process for such projects: confer
-    <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>,
-    for example.  Do we need this, too?
-
-
-# Eclipse
-
-OK for testing -- but I'd very much hope that it *just works* as soon as we
-provide the required Java platform.
-
-
-# Java Bindings
-
-
-## Design Principles
-
-  * Generally ack.
-
-
-### MIG
-
-  * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
-
-      * (Unless you want to make MIG's own code (that is, not the generated
-        code, but MIG itself) look a bit more nice, too.)  ;-)
-
-  * There are also alternatives to MIG.  If there is interest, the following
-    could be considered:
-
-      * FLICK ([[!GNU_Savannah_task 5723]]).  [[tschwinge]] has no idea yet if
-        there would be any benefits over MIG, like better modularity (for the
-        backends)?  If we feel like it, we could spend a little bit of time on
-        this.
-
-      * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
-        entirely in C Preprocessor macros.  While this is obviously not
-        directly applicable, perhaps we can get some ideas from it.
-
-      * Anything else that would be worth having a look at?  (What are other
-        microkernels using?)
-
-
-### `mach_msg`
-
-  * Seems like the right approach to [[tschwinge]], but hasn't digested all the
-    pecularities yet.  Will definitely need more time.
-
-
-# GSoC Site Discussion
-
-  * Discussion items from
-    <http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jkoenig/1>
-    should be copied here:
-
-      * technical bits (obviously);
-
-      * also the *why do we want Java bindings* reasoning;
-
-      * CLISP findings should also be documented somewhere permanently.
-
-          * We should probaby open up a *languages for Hurd* section on the web
-            pages ([[!taglink open_issue_documentation]]).