Index: mojo/ipc/message/README |
diff --git a/mojo/ipc/message/README b/mojo/ipc/message/README |
new file mode 100644 |
index 0000000000000000000000000000000000000000..abf41e44e4aeb751bb88cc6f12739b707744da0c |
--- /dev/null |
+++ b/mojo/ipc/message/README |
@@ -0,0 +1,33 @@ |
+MESSAGE FORMAT |
+============== |
+ |
+A Mojo IPC message resembles a property bag, with ordinals as property names. |
+ |
+Message: |
+ [ MessageName | MessageSize | Field_1 | Field_2 | ... | Field_N ] |
+ |
+MessageName: |
+ [ U32 ] |
+ |
+MessageSize: |
+ [ U32 ] |
+ |
+Field: |
+ [ FieldHeader | FieldValue ] |
+ |
+FieldHeader: |
+ [ FieldName | FieldType ] |
+ |
+FieldName: |
+ [ U16 ] |
+ |
+FieldType: |
+ [ U16 ] |
vtl
2013/09/12 01:16:10
Another thought occurred to me: Maybe we should st
|
+ |
+FieldValue: |
+ [ U32 ] |
vtl
2013/09/11 17:37:16
I guess by "U32" here, you mean any 32 bits of dat
|
+ [ U64 ] |
vtl
2013/09/11 17:37:16
Is there any desire to have 64-bit quantities be a
|
+ [ FieldSize | FieldBytes ] |
vtl
2013/09/11 17:37:16
Similarly, do we want to insist that FieldBytes be
|
+ |
vtl
2013/09/11 17:37:16
It occurs to me that we want to assign ordinals to
|
+FieldSize: |
+ [ U32 ] |