IRC.

1 files changed, 0 insertions, 119 deletions

diff --git a/microkernel/mach/mig/structured_data.mdwn b/microkernel/mach/mig/structured_data.mdwn
deleted file mode 100644
index 1c8abe08..00000000
--- a/microkernel/mach/mig/structured_data.mdwn
+++ /dev/null
@@ -1,119 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-# IRC, freenode, #hurd, 2013-06-25
-
-    <teythoon> is there a nice way to get structured data through mig that I
-      haven't found yet?
-    <teythoon> say an array of string triples
-    <braunr> no
-    <teythoon> :/
-    <braunr> but you shouldn't need that
-    <teythoon> my use case is getting info about fs translators from init to
-      procfs
-
-[[community/gsoc/project_ideas/mtab]].
-
-    <teythoon> should I go for an iterator like interface instead?
-    <braunr> depends
-    <braunr> how many do you need ?
-    <braunr> you could go for a variable sized array too
-    <braunr> have a look at what already exists
-    <teythoon> records, maybe 10-15, depends on many fs translators are running
-    <braunr> a variable sized array is ok if the size isn't too big (and when i
-      say too big, i mean hundreds of MiB)
-    <braunr> an iterator is ok too if there aren't too many items
-    <braunr> you may want to combine both (i think that's what proc does)
-    <braunr> be aware that the maximum size of a message is limited to 512 MiB
-    <teythoon> yeah I saw the array[] of stuff stuff, but array[] of string_t
-      does not work, I guess b/c string_t is also an array
-    <teythoon> how would I send an array of variable length strings?
-    <braunr> i'm not sure you can
-    <braunr> or maybe out of line
-    <teythoon> somehow I expected mig to serialize arbitrary data structures,
-      maybe it's to old for that?
-    <teythoon> yeah, I read about uot of line, but that seems overkill
-    <braunr> it is old yes
-    <braunr> and not very user friendly in the end
-    <braunr> let me check
-    <teythoon> we could stuff json into mig...
-    <braunr> see proc_getallpids for example
-    <braunr> we could get rid of low level serialization altogether :p
-    <teythoon> hah, exactly what  I was looking at
-    <braunr> (which is what i'll do in x15)
-    <braunr> type pidarray_t = array[] of pid_t;
-    <teythoon> but that is trivial b/c its array[] of pid_t
-    <braunr> and always have the server writing guide near you
-    <teythoon> yes
-    <braunr> well, make one big string and an array of lengths :p
-    <teythoon> thought about that and said to myself, there must be a better
-      way that I haven't found yet
-    <braunr> or one big string filled with real null-terminated c strings that
-      you keep parsing until you ate all input bytes
-    <braunr> i'm almost certain there isn't
-    <braunr> type string_t = c_string[1024]; /* XXX */
-    <teythoon> yes
-    <braunr> even that isn't really variable sized
-    <teythoon> you think anyone would object to me putting a json encoder in
-      /hurd/init? it is probably better than me at serializing stuff...
-    <braunr> try with mig anyway
-    <braunr> the less dependencies we have for core stuff, the simpler it is
-    <braunr> but i agree, mig is painful
-    <teythoon> would it be too hacky if I abused the argz functions? they do
-      exactly what I'd need
-
-
-## IRC, freenode, #hurd, 2013-06-26
-
-    <teythoon> there is https://code.google.com/p/protobuf-c/ and it has a rpc
-      mechanism and I believe one could plug arbitrary transports easily
-    <braunr> please don't think about it
-    <braunr> we really don't want to add another layer of serialization
-    <braunr> it's better to completely redesign mach ipc anyway
-    <braunr> and there is a project for that :p
-    <teythoon> ive seen x15
-    <teythoon> just food for thought
-    <braunr> i've studied google protocol buffers
-    <braunr> and fyi, no, it wouldn't be easy to plug arbitrary transports on
-      top of mach
-    <braunr> there is a lot of knowledge about mach ports in mig
-
-[[community/gsoc/project_ideas/mtab]].
-
-    <teythoon> but again I face the challenge of serializing a arbitrary sized
-      list of arbitrary sized strings
-    <braunr> yes
-    <teythoon> list of ports is easier ;) but I think its worthwile
-    <teythoon> so what about abusing argz* for this? you think it's too bad a
-      hack?
-    <braunr> no since it's in glibc
-    <teythoon> awesome :)
-    <braunr> but i don't remember the details well and i'm not sure the way you
-      use it is safe
-    <teythoon> yeah, I might have got the details wrong, I hadn't had the
-      chance to test it ;)
-
-    <braunr> about this dynamic size problem
-    <braunr> a "simple" varying size array should do
-    <braunr> you can easily put all your strings in there
-    <teythoon> seperated by 0?
-    <braunr> yes
-    <teythoon> that's exactly what the argz stuff does
-    <braunr> you'll get the size of the array anyway, and consume it until
-      there is no byte left
-    <braunr> good
-    <braunr> but be careful with this too
-    <braunr> since translators can be run by users, they somtimes can't be
-      trusted
-    <braunr> and even a translator running as root may behave badly
-    <braunr> so careful with parsing
-    <teythoon> noted