mojo/ipc/message/README - Issue 23629032: mojo: MessageBuilder

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Side by Side Diff: mojo/ipc/message/README

Issue 23629032: mojo: MessageBuilder (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Add support for a string field type. Created 7 years, 3 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

OLD	NEW
(Empty)
	1 MESSAGE FORMAT

	2 ==============

	3

	4 A Mojo IPC message resembles a property bag, with ordinals as property names.

	5

	6 Message:

	7 [ MessageName \| MessageSize \| Field_1 \| Field_2 \| ... \| Field_N ]

	8

	9 MessageName:

	10 [ U32 ]

	11

	12 MessageSize:

	13 [ U32 ]

	14

	15 Field:

	16 [ FieldHeader \| FieldValue ]

	17

	18 FieldHeader:

	19 [ FieldName \| FieldType ]

	20

	21 FieldName:

	22 [ U16 ]

	23

	24 FieldType:

	25 [ U16 ]
	vtl 2013/09/12 01:16:10 Another thought occurred to me: Maybe we should st Another thought occurred to me: Maybe we should steal a few bits from this and encode the size? E.g., take 2 bits and have them mean: 00 - 0 bytes 01 - 4 bytes 10 - 8 bytes 11 - size specified by FieldSize (obviously, taking 3 bits gives you a bit more flexibility). The advantage is forwards-compatibility, so that you can skip fields whose FieldTypes that you don't know about.
	26

	27 FieldValue:

	28 [ U32 ]
	vtl 2013/09/11 17:37:16 I guess by "U32" here, you mean any 32 bits of dat I guess by "U32" here, you mean any 32 bits of data (per FieldType). Which I guess also implies that chars, bools, int16_ts, etc. all get padded out to 32 bits (which I guess is fine), right?
	29 [ U64 ]
	vtl 2013/09/11 17:37:16 Is there any desire to have 64-bit quantities be a Is there any desire to have 64-bit quantities be aligned (on 8-byte boundaries)? If added <empty> as a possible FieldValue, we could reserve FieldName=0, FieldType=0 as an empty padding field. (We could also do some optimizations, e.g., optimize bools by having separate "bool_true" and "bool_false" FieldTypes.)
	30 [ FieldSize \| FieldBytes ]
	vtl 2013/09/11 17:37:16 Similarly, do we want to insist that FieldBytes be Similarly, do we want to insist that FieldBytes be padded out to a multiple of 4 bytes?
	31
	vtl 2013/09/11 17:37:16 It occurs to me that we want to assign ordinals to It occurs to me that we want to assign ordinals to passed handles also. Should this be done by adding data to the message data itself (e.g., a handle FieldType, with the FieldValue indicating the index in the array of handles) or separately? (I favor the former, since it keeps the message serialization format separate from the transport primitives.)
	32 FieldSize:

	33 [ U32 ]

OLD	NEW

« mojo/ipc/core/ipc_handle.h ('K') | « mojo/ipc/core/ipc_handle.h ('k') | mojo/ipc/message/ipc_message.h » ('j') | mojo/ipc/message/ipc_message.h » ('J')