- From: <bugzilla@jessica.w3.org>
- Date: Wed, 16 May 2012 00:44:01 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073 Summary: 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 kn Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: contributor@whatwg.org QAContact: public-webapps-bugzilla@w3.org CC: mike@w3.org, public-webapps@w3.org 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 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Wednesday, 16 May 2012 00:44:22 UTC