- 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