Re: [protobuf] Generated Javascript Protobufs and Grunt

2017-02-21 Thread gunnar . gissel
Thanks for the help, I appreciate it

I think it's worth noting, for those that follow in my footsteps, that when 
you do a GET vs a RESTful endpoint you don't get raw bytes back.  The most 
expedient thing I found (and please set me straight if I'm wrong), was to 
declare the response type to be a blob then turn the blob into an array 
buffer, then deserialize that

Like so:

var xhr = new XMLHttpRequest();
xhr.open("GET",'http://localhost:8080/people.proto', true);
xhr.responseType = 'blob';
xhr.onload = function(e){
  if(this.status === 200){
var arrBuff = null;
var fileReader = new FileReader();
fileReader.onload = function(){
  //here we've translated the blob into something our protobuf 
javascript can understand
  arrBuff = this.result;
  //here we get an object to work with
  var pkg = proto.package.MyPeopleProto.deserializeBinary(arrBuff);
}
//here we read the blob
fileReader.readAsArrayBuffer(this.response);
  }
}




On Tuesday, February 21, 2017 at 7:44:04 AM UTC-9, Adam Cozzette wrote:
>
> Ok, that's good you were able to get things working with CommonJS-style 
> imports. To parse the raw bytes into an object you will want to call 
> MyProto.deserializeBinary(bytes).
>
> On Wed, Feb 15, 2017 at 3:42 PM, Gunnar Gissel - NOAA Federal <
> gunnar...@noaa.gov > wrote:
>
>> FWIW, switching to commonjs style imports seems to work.
>>
>> Now I'm wondering how do I get from bytes to objects?  Passing the bytes 
>> into the generated constructor doesn't seem to work - I'm still seeing 
>> binary values where I expect to see textual values
>>
>> On Wed, Feb 15, 2017 at 10:20 AM,  
>> wrote:
>>
>>> I don't expect that the code got pulled into the protobuf library 
>>> because I'm pulling the generated javascript files out of a jar created by 
>>> maven and using them on a box that has been set up solely for doing the 
>>> javascript side of things.  The protobuf install there is via npm, although 
>>> I had to add message.js and map.js files to the closure compiler to get it 
>>> working there.  It is possible I've gone about acquiring protobuf for my 
>>> javascript build entirely wrong, though.
>>>
>>> On Wednesday, February 15, 2017 at 10:16:42 AM UTC-9, gunnar...@noaa.gov 
>>> wrote:

 Sure thing!

 Gruntfile.js:

 module.exports = function(grunt){
   
   require('google-closure-compiler').grunt(grunt);

   grunt.initConfig({
 pkg: grunt.file.readJSON('package.json'),
 'closure-compiler': {
   my_target: {
 files: {
   'target/full.js': ['js/**.js']
 },
 options: {
   js: [
 'node_modules/google-closure-library/**.js', 
 '!node_modules/google-closure-library/**_test.js', 
 '!node_modules/google-closure-library/**_perf.js', 
 '!node_modules/google-closure-library/**tester.js', 
 
 '!node_modules/google-closure-library/**promise/testsuiteadapter.js', 
 '!node_modules/google-closure-library/**osapi/osapi.js', 
 '!node_modules/google-closure-library/**svgpan/svgpan.js', 
 '!node_modules/google-closure-library/**alltests.js', 
 '!node_modules/google-closure-library/**node_modules**.js', 
 
 '!node_modules/google-closure-library/**protractor_spec.js', 
 
 '!node_modules/google-closure-library/**protractor.conf.js', 
 
 '!node_modules/google-closure-library/**browser_capabilities.js', 
 '!node_modules/google-closure-library/doc/**.js', 
 'node_modules/google-protobuf/**.js',
 'js/missing-google-crap/message.js',
 'js/missing-google-crap/map.js',
 'js/person.js'
   ],
   compilation_level: 'SIMPLE',
   language_in: 'ECMASCRIPT5',
   create_source_map: 'target/full.js.map'
   
 }
   }
 }
   });


   grunt.registerTask('default', ['closure-compiler']);
 }


 The javascript is generated via Maven, so here is the command we are 
 using:


   com.github.os72
   protoc-jar-maven-plugin
   3.0.0
   
   
   generate-sources
   
   run
   
   
   3.0.0 
   
   src/main/resources/proto
   
   
   
   java
   none
   
 src/main/gen

Re: [protobuf] Generated Javascript Protobufs and Grunt

2017-02-21 Thread 'Adam Cozzette' via Protocol Buffers
Ok, that's good you were able to get things working with CommonJS-style
imports. To parse the raw bytes into an object you will want to call
MyProto.deserializeBinary(bytes).

On Wed, Feb 15, 2017 at 3:42 PM, Gunnar Gissel - NOAA Federal <
gunnar.gis...@noaa.gov> wrote:

> FWIW, switching to commonjs style imports seems to work.
>
> Now I'm wondering how do I get from bytes to objects?  Passing the bytes
> into the generated constructor doesn't seem to work - I'm still seeing
> binary values where I expect to see textual values
>
> On Wed, Feb 15, 2017 at 10:20 AM,  wrote:
>
>> I don't expect that the code got pulled into the protobuf library because
>> I'm pulling the generated javascript files out of a jar created by maven
>> and using them on a box that has been set up solely for doing the
>> javascript side of things.  The protobuf install there is via npm, although
>> I had to add message.js and map.js files to the closure compiler to get it
>> working there.  It is possible I've gone about acquiring protobuf for my
>> javascript build entirely wrong, though.
>>
>> On Wednesday, February 15, 2017 at 10:16:42 AM UTC-9, gunnar...@noaa.gov
>> wrote:
>>>
>>> Sure thing!
>>>
>>> Gruntfile.js:
>>>
>>> module.exports = function(grunt){
>>>
>>>   require('google-closure-compiler').grunt(grunt);
>>>
>>>   grunt.initConfig({
>>> pkg: grunt.file.readJSON('package.json'),
>>> 'closure-compiler': {
>>>   my_target: {
>>> files: {
>>>   'target/full.js': ['js/**.js']
>>> },
>>> options: {
>>>   js: [
>>> 'node_modules/google-closure-library/**.js',
>>> '!node_modules/google-closure-library/**_test.js',
>>> '!node_modules/google-closure-library/**_perf.js',
>>> '!node_modules/google-closure-library/**tester.js',
>>> '!node_modules/google-closure-library/**promise/testsuiteada
>>> pter.js',
>>> '!node_modules/google-closure-library/**osapi/osapi.js',
>>> '!node_modules/google-closure-library/**svgpan/svgpan.js',
>>> '!node_modules/google-closure-library/**alltests.js',
>>> '!node_modules/google-closure-library/**node_modules**.js',
>>> '!node_modules/google-closure-library/**protractor_spec.js',
>>>
>>> '!node_modules/google-closure-library/**protractor.conf.js',
>>>
>>> '!node_modules/google-closure-library/**browser_capabilities
>>> .js',
>>> '!node_modules/google-closure-library/doc/**.js',
>>> 'node_modules/google-protobuf/**.js',
>>> 'js/missing-google-crap/message.js',
>>> 'js/missing-google-crap/map.js',
>>> 'js/person.js'
>>>   ],
>>>   compilation_level: 'SIMPLE',
>>>   language_in: 'ECMASCRIPT5',
>>>   create_source_map: 'target/full.js.map'
>>>
>>> }
>>>   }
>>> }
>>>   });
>>>
>>>
>>>   grunt.registerTask('default', ['closure-compiler']);
>>> }
>>>
>>>
>>> The javascript is generated via Maven, so here is the command we are
>>> using:
>>>
>>> 
>>>com.github.os72
>>>protoc-jar-maven-plugin
>>>3.0.0
>>>
>>>
>>>generate-sources
>>>
>>>run
>>>
>>>
>>>3.0.0
>>>
>>>src/main/resources/proto
>>>
>>>
>>>
>>>java
>>>none
>>>
>>> src/main/gen
>>>
>>>
>>> 
>>> descriptor
>>> none
>>> 
>>> src/main/resources/protoDesc/
>>>
>>>
>>> js
>>> none
>>> 
>>> src/main/resources/js/
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> On Wednesday, February 15, 2017 at 9:40:03 AM UTC-9, Adam Cozzette wrote:

 If you could share your gruntfile that would be great. I would be
 interested to know in particular the protoc command used to generate the
 Javascript. Also it would be good to verify that the generated code for
 that proto did not somehow get pulled into the protobuf build and end up
 being part of the actual protobuf library.

 On Wed, Feb 15, 2017 at 9:10 AM, 

Re: [protobuf] How to distinguish between messages?

2017-02-21 Thread Brian Palmer
On Sun, Feb 19, 2017 at 5:26 PM pbaranov  wrote:

> It's probably something trivial but I can't figure it out :( I have 2
> messages that have similar structure and when I try to encode message #1
> and decode it as message #2 it works just fine. Why??? If that's how it is
> supposed to work how to distinguish between them? Please advise.
>

You're not missing anything; the standard wire format for protocol buffers
does not include the names of anything, only the fields and types.  Your
communication protocol will need some higher level coordination to handle
what types of message should be sent.

One possible way of encoding this sort of information into a protocol
buffer is to use a container message, such as

message OuterMessage {
  oneof messages {
 Msg1 msg1 = 1;
 Msg2 msg2 = 2;
   }
}

Where each possible message is specified in the oneof group. Then in your
C++ code handling the received outer message, you can switch on the result
of messages_case() to know which inner message was actually sent.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.