This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17073 - Formatting Binary Data
Summary: Formatting Binary Data
Status: RESOLVED NEEDSINFO
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebSocket API (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-16 00:44 UTC by contributor
Modified: 2012-07-25 03:03 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2012-05-16 00:44:01 UTC
Specification: http://www.w3.org/TR/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Dygear@gmail.com - Mark 'Dygear' Tomlin

With the View Data Specification gaining maturity, I wanted to add something
to it that I feel would make a huge impact on the power of Binary Data and Web
Sockets. I was hoping that someone with quite a lot more knowlage then me
would be able to tell me if the idea was feasible, and if it could be
implemented before the View Data / Binary Web Sockets spec was done.

So the idea being that, in very much the same way the php's pack and unpack
functions allow for the conversion of binary data, into php arrays I would
like to do the same within JavaScript, but natively supported within the
specification, and handled by the browsers C++ engine, not by the JavaScript
run time. This is to ensure that packet based information could be handled by
JavaScript without very many problems for the programmer.

An example of the format as to what this would look like is as follows. (Noted
that I moved away from PHP's implementation slightly in the characters used
for each data type.)

Name	Bit Len Format Character
bit	1	t
nibble	4	n

Padding Type	Null	Space
string	8	a	A

		Signed	Unsigned
bit	8	b	B
short	16	s	S
long	32	l	L


Float Type	Float	Decimal
float	32	f	F
double	64	d	D
quad	128	q	Q

Markups for format.
Anything within a {} is a struct within the format, mainly useful for an array
of structs so it should be used with the [] most of the time. [] refers to a
variable already formatted and on the same level as the reference, that we
wish to use the value of. () refers to the internal structure of a datatype,
or getting specific information from within it's bits.

So if we take this information and apply it to a packet, that as a struct
within a struct we get get a pretty powerful experience. If we take for
example the LFS Packet MCI (Muli-Car Info) that as another structure built
into it we can parse this easily with this information The MCI packet, and
CompCar data structure is as follows.

bSize/bType/bReqI/bNumC/{SNode/sLap/bPLID/bPosition/bInfo(tBlue/tYellow/t3/tLa
g/tFirst/tLast)/bSp3/lX/lY/lZ/sSpeed/sDirection/sHeading/sAngVel}[NumC]Info

Data Types are in bold in the above string back references are underlined and
internal references are italicized, so you know where they are coming from in
my example  Below is the Struct of this as shown in C.

struct IS_MCI // Multi Car Info - if more than 8 in race then more than one of
these is sent

{

	uint8	Size;		// Size in Bytes = 4 + (NumC * 28)

	uint8	Type;		// Always ISP_MCI (38)

	uint8	ReqI;		// 0 unless this is a reply to an TINY_MCI
request

	uint8	NumC;		// number of valid CompCar structs in this
packet



	CompCar Info[8];	// car info for each player, 1 to 8 of these
(NumC)

};

struct CompCar // Car info in 28 bytes - there is an array of these in the MCI
(below)

{

	uint16	Node;		// current path node

	uint16	Lap;		// current lap

	uint8	PLID;		// player's unique id

	uint8	Position;	// current race position : 0 = unknown, 1 =
leader, etc...

	uint8	Info;		// flags and other info - see below

	uint8	Sp3;

	int32	X;		// X map (65536 = 1 metre)

	int32	Y;		// Y map (65536 = 1 metre)

	int32	Z;		// Z alt (65536 = 1 metre)

	uint16	Speed;		// speed (32768 = 100 m/s)

	uint16	Direction;	// direction of car's motion : 0 = world y
direction, 32768 = 180 deg

	uint16	Heading;	// direction of forward axis : 0 = world y
direction, 32768 = 180 deg

	int16	AngVel; 	// signed, rate of change of heading : (16384
= 360 deg/s)

};

The only thing really missing is the * oparator that repeats until it has no
more input, and the @ NUL-fill oparator, as I've not discussed them, but they
should also be implemented.


Posted from: 68.197.216.150
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5
Comment 1 Ted Mielczarek [:ted] 2012-05-18 16:32:45 UTC
This sounds almost exactly like the binary data proposal in ECMAScript:
http://wiki.ecmascript.org/doku.php?id=harmony:binary_data

(this is one of the candidate proposals for ES6, AIUI)
Comment 2 Ian 'Hixie' Hickson 2012-07-10 21:29:04 UTC
This doesn't seem to be a proposal for the WebSockets API, so this may be misplaced. I recommend posting this suggestion to the address given in the draft on which you are commenting.