What about ECMAScript bindings, so that it can be used for JavaScript or Flash's ActionScript?

[sbavince]

That possibly could fix some performance issues when streaming very
frequently changing data down to a web client.

[Kenton Varda]

On Tue, Jul 8, 2008 at 12:54 PM, sbavince <vincent...@gmail.com> wrote:

That possibly could fix some performance issues when streaming very
frequently changing data down to a web client.

Seems useful.  Although, some issues with this are:
- You'd need to include a parser in your client-side app, which may be too much extra code to be worth it.
- It might be hard to write an efficient parser in Javascript.  Meanwhile, browsers normally have built-in support for parsing XML which is likely to be written in native code and thus be faster.  Similarly, if you are using JSON and you trust your data source, you can just eval() it, which is probably going to be faster than parsing protobufs in pure Javascript.  Unless you have a really awesome Javascript implementation...

But, that said, I think this deserves careful investigation.

[Joey Schorr]

I've actually had an implementation for ECMAScript planned for a
while, and an initial stab at a compiler to ECMAScript spec'ed out.
The basic idea I had was to have the compiler generate the interfaces
for each message type and as well have a common interface on the
ECMAScript side for implementing "serializers." This way, the default
serialization method could very well be JSON, while others could come
along and implement other intermediate formats, most notebly the PB
binary format and XML. While this technically strays from the goal of
PB (being faster than XML and all), it would allow us to have a good
deal of the benefits of PB (same interface on both ends) without the
speed downsides of the binary format on the client side (of course,
with an obvious speed downside on the server side).

As I'm on vacation now, I won't be working on this until Aug, but if
anyone wants to contribute starting then, let me know! :-)

Thanks,
Joey Schorr
jsc...@google.com

On Jul 8, 4:02 pm, "Kenton Varda" <ken...@google.com> wrote:

[jlar]

Hi Kenton,

On Jul 8, 10:02 pm, "Kenton Varda" <ken...@google.com> wrote:
> Seems useful. Although, some issues with this are:
> - You'd need to include a parser in your client-side app, which may be too
> much extra code to be worth it.

Maybe it could be part of the new google initiative to centrally host
JavaScript libraries. That would at least reduce the bandwidth
considerations.

> - It might be hard to write an efficient parser in Javascript. Meanwhile,
> browsers normally have built-in support for parsing XML which is likely to
> be written in native code and thus be faster. Similarly, if you are using
> JSON and you trust your data source, you can just eval() it, which is
> probably going to be faster than parsing protobufs in pure Javascript.
> Unless you have a really awesome Javascript implementation...

I think the major performance bottleneck for AJAX applications is
normally not the parsing of the data but often the transmission of
data. But I might be wrong.

Regards,
Jesper