path: root/open_issues/rpc_stub_generator.mdwn
diff options
Diffstat (limited to 'open_issues/rpc_stub_generator.mdwn')
1 files changed, 48 insertions, 1 deletions
diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn
index 05eb53b8..d4622d67 100644
--- a/open_issues/rpc_stub_generator.mdwn
+++ b/open_issues/rpc_stub_generator.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!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
@@ -97,3 +97,50 @@ License|/fdl]]."]]"""]]
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>
+ <neal> in the same directory, you there are headers that use it
+ <braunr> neal: cf.
+ <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 :)