On Sat, Apr 2, 2011 at 3:53 PM, Jeffrey Damick <jeffreydam...@gmail.com>wrote:

> This may be a naive question, but wouldn't the format in text_format
> be a prime example another "protocol"? It seems that if you are able
> to reuse the vistor generate the text format, then it would be easily
> extendable by others for json or the latest encoding of the week..  I
> look forward to seeing it pushed into the tree.
>

TextFormat is already implemented purely in terms of public interfaces --
namely, the reflection interface.  Thus it is already possible to write,
say, a JSON encoder/decoder for protobufs, and indeed several people have
done this.

The current visitor proposal (which I haven't had time to work on in awhile,
but will get back to eventually...) does not provide any new way to
implement TextFormat, because all visitor classes are type-specific.  In
other words, to implement TextFormat via visitors you would need to write an
implementation for every single type, rather than one implementation that
covers all types.  This could perhaps be solved by inventing some sort of
generic visitor adapter, but I haven't done any such thing in my patch,
since reflection already solves most of the same problems.


>
> thanks
> -jeff
>
> On Feb 8, 2:34 pm, Kenton Varda <ken...@google.com> wrote:
> > On Tue, Feb 8, 2011 at 5:47 AM, Evan Jones <ev...@mit.edu> wrote:
> >
> > >  The Visitor class has two standard implementations:  "Writer" and
> > >> "Filler".  MyStream::Writer writes the visited fields to a
> > >> CodedOutputStream, using the same wire format as would be used to
> encode
> > >> MyStream as one big message.
> >
> > > Imagine I wanted a different protocol. Eg. I want something that
> checksums
> > > each message, or maybe compresses them, etc. Will I need to subclass
> > > MessageType::Visitor for each stream that I want to encode? Or will I
> need
> > > to change the code generator?
> >
> > To do these things generically, we'd need to introduce some sort of
> > equivalent of Reflection for streams.  This certainly seems like it could
> be
> > a useful addition to the family, but I wanted to get the basic
> functionality
> > out there first and then see if this is needed.
> >
> > Note that I expect people will generally only "stream" their top-level
> > message.  Although the proposal allows for streaming sub-messages as
> well, I
> > expect that people will normally want to parse them into message objects
> > which are handled whole.  So, you only have to manually implement the
> > top-level stream, and then you can invoke some reflective algorithm from
> > there.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to protobuf@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to