[Rprotobuf-yada] 3rd party add on approaches

[Romain Francois]

On 10/27/2009 05:44 PM, Saptarshi Guha wrote:
>
> Hello,
> Top posting here, since something slightly different.
> I persued 3rd party add ons. Two different approaches exist
>
> a) haskell, erlang - they parse the protoc file to write the methods
> b) c and objc -c : it is a superset of the google protoc source.
> Build process is altered and the objective c version has extra hooks.

I'm not sure to understand, so I'm not sure what I'm writing here is a 
or b.

 From what I can understand of the code, the code generator (files 
code_generator.cc and code_generator.h is abstract (or whatever is the 
C++ word) with implementations for C++, java and python.

The python implementation looks not so hard, even though I am not a C++ 
guy (the language it is written in) or a python guy (the target 
language). Also the generated file for python bindings looks much easier 
to read than the java or c++ file.

Furthermore, the files command_line_interface.* seems to indicate that 
hooks are also present so that one can register another implementation 
language:

   // Register a code generator for a language.
   //
   // Parameters:
   // * flag_name: The command-line flag used to specify an output file of
   //   this type.  The name must start with a '-'.  If the name is longer
   //   than one letter, it must start with two '-'s.
   // * generator: The CodeGenerator which will be called to generate files
   //   of this type.
   // * help_text: Text describing this flag in the --help output.
   //
   // Some generators accept extra parameters.  You can specify this 
parameter
   // on the command-line by placing it before the output directory, 
separated
   // by a colon:
   //   protoc --foo_out=enable_bar:outdir
   // The text before the colon is passed to CodeGenerator::Generate() 
as the
   // "parameter".
   void RegisterGenerator(const string& flag_name,
                          CodeGenerator* generator,
                          const string& help_text);


so there is hope that we could be able to do something like:

protoc --r_out=somedir somefile.proto

to generate R wrappers. Then we will have to decide what these wrappers 
are. S4 classes could be a good match, but is not notorious for speed ...

This approach relies on writing some R description of the proto to some 
file, than then needs to be sourced into R, etc ... it might be too heavy.


Another approach is to rely on the reflection mechanisms that are built 
in the proto lib. When I'll have some time, I'll try to expand on Dirk 
POC so that instead of manipulating a "Person" message, we use a 
"FileDescriptorProto" message, as described in the 
src/google/protobuf/descriptor.proto file.


> The advantage to a) over b) the user would not like so many protoc
> compilers , the disadvantage to a) is implicility one has to catch up
> with googles proto
> language spec( i doubt it will change).
> However writing a parse for this is not difficult.
>
> One approach is generate cpp version of the protoc and then an R
> function to scan the proto file and generate the R wrappers.

I think it already is C++ code.

>
> Saptarshi



-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/BcPw : celebrating R commit #50000
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
`- http://tr.im/yw8E : New R package : sos