Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-19 Thread Thomas Hicks
Sorry for the delayed responsemy ISP's spam filter suddenly 
decided that JUG
discussions were spam (whereas, previously, they were 
not).sometimes I hate computers.



At 09:57 AM 7/14/2008, you wrote:
Yeah, we have a huge case of NIH syndrome. This isn't the half of 
it, trust me. :) OTOH, some of the systems we've built ourselves 
have been blockbuster hits that enable much of what you know as Google today.


Yep, 'gotta admit that Google software has inspired a lot of projects
out there and raised the bar. At a previous job, Gov't customers used to
complain about the UI we delivered under a long-term, fixed contract.
I think that it had been initially acceptable but, after using 
fancier stuff (like

Google Maps) their expectations were raised considerably.




In response to your comment about backward compatibility,
Protocol Buffers are actually explicitly designed so that you can 
add fields and whatnot and still be able to read in records stored 
in the old format.


Cool, perhaps I'll have to take a closer look at them if I have
a need for a binary wire protocol. Thanks Nick,
regards,
-tom




Nick

On Jul 14, 2008, at 9:27 AM, Thomas Hicks wrote:


At 03:15 PM 7/10/2008, Nick wrote:

This is pretty cool:

http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html 



Protocol buffers are *the* lingua franca for RPCs, structured data
storage, and just about any data sharing you can think of at Google.
If you're building a distributed system and want to pass around
messages in something other (faster) than Xml, you should check out
protocol buffers.

Nick


Interesting but why didn't you guys just use CORBA and get it over with? :)

From the Google Protocol Buffer documentation:

   OK, I know what you're thinking: Yet another IDL? Yes, you 
could call it that.
But, IDLs in general have earned a reputation for being 
hopelessly complicated.


Complexity sounds like a strawman here.the major problem with 
IDLs is that
they are built upon a shared definition, which requires all parties 
to update and

recompile when the definition changes. And once you recompile, you've lost
the ability of the system to handle the old message format (so versioning is
very difficult unless you plan for it from the beginning).

Of course, these problems are ameliorated when 1) the IDL is for internal
use only and 2) you control both ends of the conversation.

I also wonder why Google didn't just use an existing protocol like Hessian:

http://caucho.com/products/hessian.xtp

Perhaps a case of NIH syndrome? ( http://en.wikipedia.org/wiki/NIH_syndrome)
regards,
-tom




Re: [jug-discussion] Google's Wire Format Goes Open Source (resend)

2008-07-17 Thread Thomas Hicks

At 03:15 PM 7/10/2008, Nick wrote:

This is pretty cool:

http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

Protocol buffers are *the* lingua franca for RPCs, structured data
storage, and just about any data sharing you can think of at Google.
If you're building a distributed system and want to pass around
messages in something other (faster) than Xml, you should check out
protocol buffers.

Nick


Interesting but why didn't you guys just use CORBA and get it over with? :)

From the Google Protocol Buffer documentation:

   OK, I know what you're thinking: Yet another IDL? Yes, you 
could call it that.
But, IDLs in general have earned a reputation for being 
hopelessly complicated.


Complexity sounds like a strawman here.the major problem with IDLs is that
they are built upon a shared definition, which requires all parties 
to update and

recompile when the definition changes. And once you recompile, you've lost
the ability of the system to handle the old message format (so versioning is
very difficult unless you plan for it from the beginning).

Of course, these problems are ameliorated when 1) the IDL is for internal
use only and 2) you control both ends of the conversation.

I also wonder why Google didn't just use an existing protocol like Hessian:

http://caucho.com/products/hessian.xtp

Perhaps a case of NIH syndrome? (http://en.wikipedia.org/wiki/NIH_syndrome)
regards,
-tom



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-14 Thread Thomas Hicks

At 03:15 PM 7/10/2008, Nick wrote:

This is pretty cool:

http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

Protocol buffers are *the* lingua franca for RPCs, structured data
storage, and just about any data sharing you can think of at Google.
If you're building a distributed system and want to pass around
messages in something other (faster) than Xml, you should check out
protocol buffers.

Nick


Interesting but why didn't you guys just use CORBA and get it over with? :)

From the Google Protocol Buffer documentation:

   OK, I know what you're thinking: Yet another IDL? Yes, you 
could call it that.
But, IDLs in general have earned a reputation for being 
hopelessly complicated.


Complexity sounds like a strawman here.the major problem with IDLs is that
they are built upon a shared definition, which requires all parties 
to update and

recompile when the definition changes. And once you recompile, you've lost
the ability of the system to handle the old message format (so versioning is
very difficult unless you plan for it from the beginning).

Of course, these problems are ameliorated when 1) the IDL is for internal
use only and 2) you control both ends of the conversation.

I also wonder why Google didn't just use an existing protocol like Hessian:

http://caucho.com/products/hessian.xtp

Perhaps a case of NIH syndrome? (http://en.wikipedia.org/wiki/NIH_syndrome)
regards,
-tom



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-14 Thread nlesiecki
Yeah, we have a huge case of NIH syndrome. This isn't the half of it,  
trust me. :) OTOH, some of the systems we've built ourselves have been  
blockbuster hits that enable much of what you know as Google today.


In response to your comment about backward compatibility, Protocol  
Buffers are actually explicitly designed so that you can add fields  
and whatnot and still be able to read in records stored in the old  
format.


Nick

On Jul 14, 2008, at 9:27 AM, Thomas Hicks wrote:


At 03:15 PM 7/10/2008, Nick wrote:

This is pretty cool:

http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

Protocol buffers are *the* lingua franca for RPCs, structured data
storage, and just about any data sharing you can think of at Google.
If you're building a distributed system and want to pass around
messages in something other (faster) than Xml, you should check out
protocol buffers.

Nick


Interesting but why didn't you guys just use CORBA and get it over  
with? :)


From the Google Protocol Buffer documentation:

   OK, I know what you're thinking: Yet another IDL? Yes, you  
could call it that.
But, IDLs in general have earned a reputation for being  
hopelessly complicated.


Complexity sounds like a strawman here.the major problem with  
IDLs is that
they are built upon a shared definition, which requires all parties  
to update and
recompile when the definition changes. And once you recompile,  
you've lost
the ability of the system to handle the old message format (so  
versioning is

very difficult unless you plan for it from the beginning).

Of course, these problems are ameliorated when 1) the IDL is for  
internal

use only and 2) you control both ends of the conversation.

I also wonder why Google didn't just use an existing protocol like  
Hessian:


http://caucho.com/products/hessian.xtp

Perhaps a case of NIH syndrome? ( http://en.wikipedia.org/wiki/NIH_syndrome)
 regards,
-tom





Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-11 Thread William H. Mitchell

At 09:53 PM 7/10/2008, Chad wrote:


These kids and their new-fangled protocols.  XML was good enough for
my grandfather, and it's good enough for me!  Why, we had to make our
angle brackets out of two sticks and baling wire...


I took a look at that link but the documentation seems incomplete -- 
I didn't see anything about specifying the number of stop bits. 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-11 Thread Chad Woolley
On Fri, Jul 11, 2008 at 1:08 AM, William H. Mitchell
[EMAIL PROTECTED] wrote:
 I took a look at that link but the documentation seems incomplete -- I
 didn't see anything about specifying the number of stop bits.

What was it Brian said about Java being the new Assembly?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-11 Thread nlesiecki

Stop bits?
On Jul 11, 2008, at 1:08 AM, William H. Mitchell wrote:


At 09:53 PM 7/10/2008, Chad wrote:


These kids and their new-fangled protocols.  XML was good enough for
my grandfather, and it's good enough for me!  Why, we had to make our
angle brackets out of two sticks and baling wire...


I took a look at that link but the documentation seems incomplete --  
I didn't see anything about specifying the number of stop bits.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-11 Thread Kit Plummer

old skewl serial processing.

On Jul 11, 2008, at 8:34 AM, nlesiecki wrote:


Stop bits?
On Jul 11, 2008, at 1:08 AM, William H. Mitchell wrote:


At 09:53 PM 7/10/2008, Chad wrote:


These kids and their new-fangled protocols.  XML was good enough for
my grandfather, and it's good enough for me!  Why, we had to make  
our

angle brackets out of two sticks and baling wire...


I took a look at that link but the documentation seems incomplete  
-- I didn't see anything about specifying the number of stop bits.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-10 Thread Warner Onstine

Very cool Nick, thanks for sharing!

-warner

On Jul 10, 2008, at 3:15 PM, nlesiecki wrote:


This is pretty cool:

http://google-opensource.blogspot.com/2008/07/protocol-buffers- 
googles-data.html


Protocol buffers are *the* lingua franca for RPCs, structured data  
storage, and just about any data sharing you can think of at  
Google. If you're building a distributed system and want to pass  
around messages in something other (faster) than Xml, you should  
check out protocol buffers.


Nick

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Warner Onstine - Programmer/Author
New book on Tapestry 4!
Tapestry 101 available at http://sourcebeat.com/books/tapestrylive.html
[EMAIL PROTECTED]
http://warneronstine.com/blog




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [jug-discussion] Google's Wire Format Goes Open Source

2008-07-10 Thread Chad Woolley
These kids and their new-fangled protocols.  XML was good enough for
my grandfather, and it's good enough for me!  Why, we had to make our
angle brackets out of two sticks and baling wire...

On Thu, Jul 10, 2008 at 9:45 PM, Warner Onstine [EMAIL PROTECTED] wrote:
 Very cool Nick, thanks for sharing!

 -warner

 On Jul 10, 2008, at 3:15 PM, nlesiecki wrote:

 This is pretty cool:


 http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

 Protocol buffers are *the* lingua franca for RPCs, structured data
 storage, and just about any data sharing you can think of at Google. If
 you're building a distributed system and want to pass around messages in
 something other (faster) than Xml, you should check out protocol buffers.

 Nick

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 Warner Onstine - Programmer/Author
 New book on Tapestry 4!
 Tapestry 101 available at http://sourcebeat.com/books/tapestrylive.html
 [EMAIL PROTECTED]
 http://warneronstine.com/blog




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]