IRC.

1 files changed, 40 insertions, 2 deletions

diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn
index 61a3fa01..344b741c 100644
--- a/community/gsoc/project_ideas/language_bindings.mdwn
+++ b/community/gsoc/project_ideas/language_bindings.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014 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
@@ -61,3 +61,41 @@ bindings](http://www.nongnu.org/hurdextras/#pith), which might serve as a
 reference if you want to work on Perl.
 
 Possible mentors: Anatoly A. Kazantsev (anatoly) for Python
+
+
+# Discussion
+
+## [[user/jkoenig/Java]]
+
+## IRC, freenode, #hurd, 2013-12-19
+
+    <antrik_> teythoon_: I don't think wrapping libtrivfs etc. for guile
+      bindings is really desirable... for the lisp bindings, we agreed that
+      it's better to hook in at a lower level, and build more lispish
+      abstractions
+    <antrik> trivfs is a C framework; it probably doesn't map very well to
+      other languages -- especially non-imperative ones...
+    <antrik> (it is arguable whether trivfs is really a good abstraction even
+      for C... but that's another discussion :-) )
+    <antrik> ArneBab: same for Python bindings. when I suggested ignoring
+      libtrivfs etc., working around the pthread problem was just a side effect
+      -- the real goal has always been nicer abstraction
+    <anatoly> antrik: agree with you
+    <anatoly> antrik: about nicer abstractions
+    <teythoon_> antrik: I agree too, but wrapping libtrivfs is much easier
+    <teythoon_> otherwise, one needs to reimplement lots of stuff to get some
+      basic functionality
+    <teythoon_> like a mig that emits your language
+    <braunr> i agree with antrik too
+    <braunr> yes, the best would be mig handling multiple languages
+
+[[!taglink open_issue_mig]].
+
+    <antrik> teythoon_: not exactly. for dynamic languages, code generation is
+      silly. just handle the marshalling on the fly. that's what the Lisp
+      bindings are doing (AFAIK)
+    <teythoon> antrik: ok, but you'd still need to parse the rpc definitions,
+      no?
+    <antrik> teythoon: yeah, you still need to parse the .defs -- unless we add
+      reflection to RPC interfaces...
+    <antrik> err, I mean introspection