Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 146 insertions, 0 deletions

diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn
new file mode 100644
index 00000000..d4622d67
--- /dev/null
+++ b/open_issues/rpc_stub_generator.mdwn
@@ -0,0 +1,146 @@
+[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
+
+[[!tag open_issue_mig]]
+
+
+# Originally in context of [[user/jkoenig/java]]
+
+  * [[tschwinge]] has to read about RMI and CORBA.
+
+  * 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?)
+
+
+# IRC, freenode, #hurd, 2012-12-27
+
+    <braunr> i'll soon have userspace on x15, and begin system calls, and of
+      course IPC
+    <braunr> and, since i personally have a strong disgust for IDLs, i was
+      thinking of manually writing the RPC "stubs", with helper functions and
+      macros
+    <braunr> what do you think of that ?
+    <pinotree> IDLs could have the advantage you can generate any kind of
+      language output out of them
+    <youpi> I'd not recommend that
+    <youpi> as ugly as IDLs are, they are useful
+    <pinotree> maybe pick something with proper per-arch types and
+      structs... :)
+    <braunr> youpi: what feature do you consider that important in an IDL ?
+    <braunr> i mean important enough to want to keep it
+    <youpi> argument matching between client and server code
+    <braunr> well obviously, but system wide protocols such as the hurd's tend
+      not to change much
+    <youpi> we've still seen bugs about that
+    <youpi> even without changing the protocol
+    <braunr> pinotree: i agree about the language thing, but wrapping libraries
+      also do
+    <braunr> what IDL would you then recommend ?
+    <pinotree> corba! :p
+    * pinotree runs
+    <braunr> well don't run
+    <braunr> it's actually at the top of my list :p
+    <braunr> the parser is free, and allows writing custom backends
+    <braunr> and there is already support for many languages
+    * pinotree some time ago fixed omniorb in debian
+    <pinotree> (to compile on hurd, i mean)
+    <braunr> i thought i could delay this problem some more but it's actually
+      coming quite fast :/
+    <braunr> i suppose it would make sense to use an already popular IDL so
+      that support for other languages is readily available
+    <pinotree> and/or people already know it
+    <braunr> hm that's secondary imo
+    <braunr> it's not that hard to learn an idl (providing it's simple,
+      i.e. not mig-like)
+    <braunr> hm how about google protocol buffers ?
+    <pinotree> wow, not bad at a first glance (never seen it)
+    <pinotree> structs, optional fields, builtin strings
+    <braunr> the nice thing about it is that it focuses on serialization most,
+      but has basic rpc support that allows using whatever communication
+      channel you want
+    <braunr> it may still be overkill for a microkernel based system
+    <pinotree> otoh rpc is everything in a microkernel-based os
+    <braunr> when i say overkill, i mean too slow
+    <pinotree> we still have 1024-sized string_t...
+    <braunr> yes, mig is totally hairy ...
+    <braunr> hum, c++ only, no c :/
+    <pinotree> there seems to be a C compiler, install protobuf-c-compiler
+    <braunr> v0.15, doesn't seem widely used
+    <pinotree> even on 0.14 (currently in debian)
+    <braunr> it also seems to rely on contiguous messages, whereas i want
+      scatter-gather to be used with x15
+    <braunr> once more, i fell back on omg idl
+    <braunr> oh, there is also flick that looks interesting
+
+
+# IRC, freenode, #hurd, 2013-13-16
+
+    <tschwinge> braunr: By the way, regarding your recent IDL considerations
+      (and I too suggest using some kind of RPC generator basone on whichever
+      IDL) -- are you aware that for Viengoos, Neal has written a RPC stub
+      generator entirely in C Preprocessor macros?  No idea whather that's
+      suitable for your case, but may be worth having a look at.
+    <neal> it probably isn't easy to port to Mach
+    <neal> genode has an ipc generator as well
+    <neal> which is written in a real langugage
+    <neal> that might be worth checking out as well
+    <neal> (note: I haven't followed the conversation at all.)
+    <braunr> i was considering using macros only too actually
+    <braunr> (i thought genode had switched to complex c++ templates)
+    <neal> dunno
+    <neal> I'm not up to date
+    <neal> macros are nice, but marshalling complicated data structures is hard
+    <sekon_> why implement it with just macros ??
+    <neal> no lexer, no parser
+    <neal> no special special tools
+    <neal> the first are a burden
+    <neal> the latter is a pain
+    <neal>
+      http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal
+    <neal> in the same directory, you there are headers that use it
+    <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05
+    <braunr> tschwinge: why do you recommend an IDL ?
+    <neal> braunr: What about it?
+    <braunr> neal: it shows the difference between the earlier ipc/rpc
+      interface, and the new one based only on templates and dynamic
+      marshalling using c++ streams
+    <neal> ok
+    <tschwinge> braunr: In my book, the definition of RPC interfaces is just
+      "data" in the sense that it describes data structures (exchanged
+      messages) and as such should be expressed as data (by means of an IDL),
+      instead of directly codifying it in a specific programming language.
+    <tschwinge> Of course, there may be other reasons for doing the latter
+      anyway, such as performance/optimization reasons.
+    <braunr> tschwinge: well, from my pov, you're justifying the use of an idl
+      from the definition of an rpc
+    <braunr> i'm not sure it makes much sense for me
+    <braunr> in addition, the idl becomes the "specific programming language"
+    <tschwinge> Well, I see it as data that has to be translated into several
+      formats: different programming languages' stub code.
+    <braunr> you could consider c the "common" language :)