rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 146 deletions

diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn
deleted file mode 100644
index d4622d67..00000000
--- a/open_issues/rpc_stub_generator.mdwn
+++ /dev/null
@@ -1,146 +0,0 @@
-[[!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 :)