proton-c/bindings/javascript/TODO - qpid-proton - Git at Google

 Qpid Proton JavaScript Language Bindings TODO List
 ==================================================

 Network code is currently limited to a WebSocket transport, including for Node.js
 It would be good to allow a configurable transport so that Node.js and Chrome
 packaged apps could use native TCP sockets.

 The JavaScript binding is pure JavaScript, which has been trans-compiled from C
 to JavaScript using emscripten. This allows the same code to be used in a browser
 and Node.js, but it potentially has a performance penalty in Node.js. An alternative
 for Node.js might be to build a SWIG binding (recent versions of SWIG support
 JavaScript). This should be viewed as a complementary not competing approach as
 it would only work for environments like Node.js and definitely *not* browser
 environments, which clearly require pure JavaScript.

 Optimisation are enabled for compiling and linking but there hasn't been any
 profiling done yet. The binding code *shouldn't* be the bottleneck but it's
 always possible that I messed up.

 Error handling is nowhere near as good as it should be, though this is mostly
 because Messenger itself is a bit lacking on the error handling/recovery front.

 Although described as "Proton" this is currently a JavaScript binding for Messenger
 and associated Message & Data classes. There has been some talk on the user list
 of an alternative reactive API based on proton Engine. This might ultimately be
 a better fit for JavaScript but it is very much in its infancy and I haven't
 really looked at it yet.

 proton-j seems to use hawt-dispatch, which is modelled after Grand Central
 Dispatch so I need to work out what it's using it do do and whether there are
 parallels in proton-c

 Although the WebSocket transport uses the sub-protocol 'AMQPWSB10' as specified
 in http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/amqp-wsb-v1.0.html
 section 2.1 it is not technically compliant with the spec. as the AMQP data is
 created by the proton-c code, which produces a data-stream for the TCP transport
 whereas the WebSocket spec. seems to want to make use of the fact that WebSocket
 is a frame based transport (whereas TCP is not). This is quite hard to resolve
 as the binding simply sends the contents of the octet buffer created by proton
 over the transport and thus to make this binding compliant with the spec. would
 require a change to the underlying proton-c code! It is possible that this may be
 done in future as SCTP support would require the ability to push AMQP frames too.
 In the mean time fortunately the Java Broker WebSocket transport is actually
 tolerant of this off-spec. behaviour. My personal view is that both approaches
 should be valid and in particular using the standard TCP framing means that it
 is straightforward to create WebSocket<->TCP proxies, which is useful given that
 only the Java Broker currently has a native WebSocket transport.
	Qpid Proton JavaScript Language Bindings TODO List
	==================================================

	Network code is currently limited to a WebSocket transport, including for Node.js
	It would be good to allow a configurable transport so that Node.js and Chrome
	packaged apps could use native TCP sockets.

	The JavaScript binding is pure JavaScript, which has been trans-compiled from C
	to JavaScript using emscripten. This allows the same code to be used in a browser
	and Node.js, but it potentially has a performance penalty in Node.js. An alternative
	for Node.js might be to build a SWIG binding (recent versions of SWIG support
	JavaScript). This should be viewed as a complementary not competing approach as
	it would only work for environments like Node.js and definitely not browser
	environments, which clearly require pure JavaScript.

	Optimisation are enabled for compiling and linking but there hasn't been any
	profiling done yet. The binding code shouldn't be the bottleneck but it's
	always possible that I messed up.

	Error handling is nowhere near as good as it should be, though this is mostly
	because Messenger itself is a bit lacking on the error handling/recovery front.

	Although described as "Proton" this is currently a JavaScript binding for Messenger
	and associated Message & Data classes. There has been some talk on the user list
	of an alternative reactive API based on proton Engine. This might ultimately be
	a better fit for JavaScript but it is very much in its infancy and I haven't
	really looked at it yet.

	proton-j seems to use hawt-dispatch, which is modelled after Grand Central
	Dispatch so I need to work out what it's using it do do and whether there are
	parallels in proton-c

	Although the WebSocket transport uses the sub-protocol 'AMQPWSB10' as specified
	in http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/amqp-wsb-v1.0.html
	section 2.1 it is not technically compliant with the spec. as the AMQP data is
	created by the proton-c code, which produces a data-stream for the TCP transport
	whereas the WebSocket spec. seems to want to make use of the fact that WebSocket
	is a frame based transport (whereas TCP is not). This is quite hard to resolve
	as the binding simply sends the contents of the octet buffer created by proton
	over the transport and thus to make this binding compliant with the spec. would
	require a change to the underlying proton-c code! It is possible that this may be
	done in future as SCTP support would require the ability to push AMQP frames too.
	In the mean time fortunately the Java Broker WebSocket transport is actually
	tolerant of this off-spec. behaviour. My personal view is that both approaches
	should be valid and in particular using the standard TCP framing means that it
	is straightforward to create WebSocket<->TCP proxies, which is useful given that
	only the Java Broker currently has a native WebSocket transport.