Protocol layers; a vote for JSON/HTTP

[johnjbarton]

The connection between user interface (client, consumer) and runtime
(server, producer) has several parts. Sorry if I don't use the
correct terminology below.

To set up the connection some choices are:
homebaked sockets
HTTP

Within the connection the data needs to be formatted:
binary,
ASCII,
XML,
JSON

To select the data, you can have
command -> data
RPC

I know that most debugger protocols use homebaked sockets, with lots
of variety on there rest of it.

I propose we work towards JSON over HTTP with the GET/POST effectively
giving commands, with comet-like Ajax for reverse traffic.

I guess the JSON bit is a easy sell. Why? Its fun, new, fits well to
JS, and browsers are building in support.

I guess that the HTTP part will be harder. But it does fit will to Web
(heh) and browsers have great support. Using JSON over HTTP helps us
leverage the huge investment in AJax, in terms of code, in terms of
tools, and in terms of developer skill set and reasoning, We will be
able to do a lot more with this choice.

Direct sockets are easier for a small team and particularly for the JS
team independent of the browser. They have lower packet over head for
small packets. These are both important advantages but historically
for a multi-application protocol the socket solution requires working
out lots of platform issues already baked in to HTTP and I anticipate
that the performance issues we need to face have to do with large
packets (60kloc JS and 1M node HTML) not lots of small packets.

Other thoughts?

jjb

[Mark Finkle]

On Jun 12, 5:38 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> I propose we work towards JSON over HTTP with the GET/POST effectively
> giving commands, with comet-like Ajax for reverse traffic.
>
> I guess the JSON bit is a easy sell. Why? Its fun, new, fits well to
> JS, and browsers are building in support.
>
> I guess that the HTTP part will be harder. But it does fit will to Web
> (heh) and browsers have great support.  Using JSON over HTTP helps us
> leverage the huge investment in AJax, in terms of code, in terms of
> tools, and in terms of developer skill set and reasoning,  We will be
> able to do a lot more with this choice.

HTTP is supported well in browser - at least one side of the HTTP
story. Bundling up a web server in the "server" side components is
certainly possible, but I wonder if we'd still see the performance
benefits when working with a small-scale web server.

[Simon Kaegi]

On Jun 12, 5:38 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:

> The connection between user interface (client, consumer) and runtime
> (server, producer) has several parts.   Sorry if I don't use the
> correct terminology below.
>
> To set up the connection some choices are:
>    homebaked sockets
>    HTTP
>
> Within the connection the data needs to be formatted:
>    binary,
>    ASCII,
>    XML,
>    JSON
>
> To select the data, you can have
>    command -> data
>    RPC
>

On Jun 12, 5:38 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:

> The connection between user interface (client, consumer) and runtime
> (server, producer) has several parts. Sorry if I don't use the
> correct terminology below.
>
> To set up the connection some choices are:
> homebaked sockets
> HTTP
>
> Within the connection the data needs to be formatted:
> binary,
> ASCII,
> XML,
> JSON
>
> To select the data, you can have
> command -> data
> RPC
>

I'm fine with JSON and command->data but am a bit leery on tunneling
the debug protocol through HTTP. I understand the desire to go with
something like web sockets but for now I'm happy enough using TCP
sockets with something like DBGP's: <message-length as ascii
string><null byte><message><null byte>. If it wouldn't be too
disruptive could we go forward with two transports?

Mike, I'd be curious what your experience with this simple packet
format was like. Was it sufficient?

[Mike Collins]

I found the packet format itself to be mostly sufficient, and could easily see the XML simply being replaced by JSON. DBGP itself is almost-but-not-quite sufficient for Javascript debugging, if you don't mind a little fudging, but of course lacks any facilities for the rest of the web runtime story.

It does take a fair bit of code to create the sockets on the FF extension side, whereas HTTP is built-in, so it's one line of code. I have no idea how hard it is to open sockets in other browsers' frameworks, but I do know that HTTP has to be really simple in all of them, and it's also technology that most web developers are already pretty familiar with.  On the other side of the connection, it may be a wash as to whether it's easier to use HTTP or bare sockets, but HTTP certainly isn't hard, there are embeddable HTTP servers for most of the popular languages these days.  It may be slightly more overhead, but I don't think anyone expects a debugging environment to be blazingly fast.  One expects to incur some performance penalty when you attempt to run a program in debug mode, so I think the main issue is what we can get working quickly and reliably in the greatest number of environments, and HTTP has an edge here.

Of course, if someone else was keenly interested in a socket-based protocol, I would encourage them to choose a simple message format like the one DBGP uses, rather than re-inventing the wheel.  One thing that might be useful, though, is the ability to specify a charset, rather than just assuming ASCII will be good enough all the time.  HTTP already  accommodates this, of course.

mc

[Nikolai Onken]

Hi all,

I just found this group through Ben and wanted to jump right in.
Please excuse if my post is slightly offtopic (I wasnt sure where to
post an introduction best).

At uxebu we have been devleoping a debugging/profiling tool called
xRay which at this point basically acts as the interface to a
debugging data provider.
We are running a simple python server which gives us stats on memory
and cpu consumption of a browser thread and are sending that
information via a socket connection to the xRay application.

You can find xRay at http://code.google.com/p/xray-project/ - it is
still very beta, but it should be fairly simple to get it running.

Everything is done using JSON, just because it is super simple to deal
with (To not be completely off topic).
At this point xRay is running within Adobe AIR because we wanted
socket connections to keep up with the performance.
xRay also supports a very simple log mechanism which sends logging
data to the xRay application using gears if available (for performance
reasons) - in the style of console.log().

In regards to HTTP, I just have played around with xRay and mobile
devices, sending simple console.logs from the the iPhone to xRay via a
simple HTTP request (gears doesn't work).
It works great, but there is a serious performance hit within the
browser, it would be interesting to look at that.

This is all for now, I will continue reading through the already
posted topics :)

Regards,

Nikolai Onken