of a deal-breaker for us due to space
requirements. Especially since we're planning to use 4 byte tags
across the board in our system so that there's enough space for a
unique tag for each attribute in our system.
Curious, and Thanks,
Tim
On Jul 8 2008, 10:13 am, Kenton Varda ken...@google.com wrote
.
An alternative which I was hoping to avoid would be to write scripts
to parse my header files, evaluate the symbols, and then write
my .proto files accordingly. I am curious if others are doing similar
things with protobufs.
Thanks,
Tim
--~--~-~--~~~---~--~~
You received
, Is anyone else using PB in this way?
Tim
On Feb 23, 1:33 pm, Joshua Haberman jhaber...@gmail.com wrote:
On Feb 23, 9:51 am, Caleb caleb.epst...@gmail.com wrote:
On Feb 6, 5:56 pm, Joshua Haberman jhaber...@gmail.com wrote:
Does proto2 support event-based decoding
of protobufs definitely
weren't designed for embedded systems, but there might be a case for taking
the Google C++ implementation and ripping out all the advanced features to
make something extremely stripped-down.
On Thu, Feb 26, 2009 at 5:27 PM, Tim timbla...@gmail.com wrote:
Anyone out
I'm interested in your work, Josh. But I'm having trouble
understanding what your goal is. I.e. what is the essence of protobufs
that you are trying to distill? And how would you differentiate your
work from Dave's protobuf-c project? And is your implementation going
to be entirely in C?
Tim
by the framework so you
don't have to do extra did the field change and if so, what should
I do about it now? checks at a higher level. Is this sort of
consideration on anyone's radar?
Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed
to go to and from string (similar to how
the new Java-style enums allow you to call valueOf to go from String
to Enum, and toString to go from Enum to String). This would be
extremely useful for us to have the capability in C++, and it seems
like this could be very easily code-generated.
Thanks,
Tim
Hi,
I am trying to build protobuf 2.0.3 on FreeBSD 7.1 and am running into
an error in the make immediately after the link step.
I run configure with the --disable-shared argument, then run make.
The make appears to compile all of the code, and successfully produces
the archives in the
I generally create web services using WCF or ASP.NET MVC. I don't get
the point of Protocol Buffers. Am I missing something?
Out of the box, WCF web services and ASP.NET MVC actions serialise my
objects to JSON or XML, using the serialisation libraries provided by
the framework. I don't need to
The consensus seems to be that the main rationale for Protocol Buffers
is cross-platform interoperability, and transferring objects between
platforms.
I can already consume JSON objects from a WCF service using JavaScript
in the web browser. I can see that if I used other platforms/languages
I
If you can show me a format which offers faster serialisation or
deserialisation than JSON in a .NET application, I'd be impressed! :)
Although I haven't heard anybody experiencing problems with the
performance of either direction in .NET with JSON or XML, the
libraries provided by the framework
This is C++.
I had not tried optimizing for CODE_SIZE. I understood that CODE_SIZE
was the precursor to and not as compact as LITE_RUNTIME.
Yes, I believe they are tag numbers, the enumeration-style numbering
of each possible response or request.
--
You received this message because you are
find a bitset type within the
proto language. Any thoughts?
-Tim
--
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
You cannot use the extension's number as the key (though I agree, that
would be nice). Instead, you need to provide the fully-qualified path
to the extended field inside square braces, e.g. [My.Extension.foo]:
'foovalue'. Take a look at the Debug() output of an extended message
and you'll see
option
would seem to be to serialize the JSON data as a protobuf Struct
representation (which in turn has interesting implications for the
receiving system). Am I missing some other option?
>
Tim
P.S. Nice work on the conformance test suite, by the way! That clarified
a *lot* of details about the expe
to instead truncate Durations and Timestamps to the
representable range and to redefine Fieldmask to drop unrepresentable
fields. This would eliminate a lot of boilerplate from implementations
(and users) of the JSON code.
Cheers,
Tim
--
You received this message because you are subscribed
rotobuf Struct, which would
have interesting implications for the receiving system. Am I missing some
other option?
Tim
P.S. Nice work on the conformance test suite, by the way! That answered a
*lot* of questions about the expected handling for protobuf JSON format.
--
You received this mes
serialize the JSON data as a protobuf Struct
representation (which in turn has interesting implications for the
receiving system). Am I missing some other option?
Tim
P.S. Nice work on the conformance test suite, by the way! That clarified
a *lot* of details about the expected handling for protobuf
I have a data modelling problem and I'm wondering if protobuf could be the
right tool to help me solve this problem.
I have data in one schema and i want to transform it to another schema.
message Dataset {
required string title = 1;
required string description = 2;
}
message Study {
Hi, just wanted to check my declaration with you guys, is it possible to
reuse the `Study` declaration in the `Denormalised`
package mypackage;
message Dataset {
required string accession = 1;
required string url_self = 2;
optional string title = 3;
optional string description = 4;
Is the Any type implemented in the python libraries yet?
I read this on the documentation
*Currently the runtime libraries for working with Any types are under
development*.
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe
On Friday, February 19, 2016 at 3:56:34 PM UTC-8, Josh Haberman wrote:
>
> Thanks a lot for tracking this down. For reference, here it is in our bug
> tracker: https://github.com/google/protobuf/issues/1243
>
> On Thursday, February 11, 2016 at 3:28:33 AM UTC-8, Ron Ben-Yosef wrote:
>>
>> Hi,
> On Mar 14, 2016, at 11:50 AM, Feng Xiao <xiaof...@google.com> wrote:
>
>
>
> On Thu, Mar 3, 2016 at 6:37 PM, Tim Kientzle <kient...@gmail.com> wrote:
>
> I think your current Any JSON design requires that protobuf serialization be
> able to fail. Th
What should the JSON coding be for the following?
message Foo {
string _field_name4 = 7;
}
Currently, the protoc tests say that the JSON field name should be
“fieldName4”, the conformance test says that the JSON field name should be
“FieldName4”. Both seem reasonable, but only one can be
andard message (one of the "well-known types") specifically designed
to store a set of field names. You might be able to achieve what you want by
providing a FieldMask with your data listing the specific fields to
be updated.
Tim
--
You received this message because you are subscribed
s odd,
since every other part of the proto3 design works equally well for systems that
are primarily JSON or primarily protobuf.
Tim
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop
> On Mar 17, 2016, at 10:04 AM, Feng Xiao <xiaof...@google.com> wrote:
>
> On Wed, Mar 16, 2016 at 7:49 PM, Tim Kientzle <kient...@gmail.com> wrote:
>
> > On Mar 14, 2016, at 7:07 PM, Feng Xiao <xiaof...@google.com> wrote:
> >
> > In google
t approach works well my proposed Any design as well. Your proxies can
still walk the object tree and validate and/or convert Any fields as necessary
for your particular systems.
But that approach is not appropriate for everyone. Your Any design cannot be
used by people that require different po
to protobuf. The actual JSON serialization is very similar to the
current Any serialization (with the addition of the extra “json” tag).
Cheers,
Tim
> On Feb 5, 2016, at 1:53 PM, Josh Haberman <haber...@google.com> wrote:
>
> Hi Tim,
>
> I think your analysis is correc
ld stick with proto2. It’s still around and will be for a long time.
Cheers,
Tim
--
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+
are
deeply baked into your systems, you can keep using it. protoc will continue to
support it for a very long time.
Cheers,
Tim
> On May 18, 2016, at 1:33 PM, Jeremy Ong <jer...@plexchat.com> wrote:
>
> Big fan of 4, 5, 6, and 7. Huge un-fan of 2, and 3. I am mixed on 1 be
exec-am'.
>
> make[2]: Nothing to be done for `install-data-am'.
>
>
This looks like it worked.
What is your concern?
Tim
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop recei
only integers in my message type, can I always assume assert
> "msg_size_before == msg_size_after"
No.
Protobuf uses variable-length integer encodings, so the size will change
depending on the exact integer values.
If you need the size to be the same, you can use "fixed32
ould be
> best to avoid creating another dependency on that GetTypeName() method when
> it might be going away in the future.
>
This seems to suggest that you don’t intend to support Any for mobile?
Tim
--
You received this message because you are subscribed to the Google Groups
&qu
support.
https://developers.google.com/protocol-buffers/docs/reference/other
Tim
>
> thanks!
>
> 2016年9月23日星期五， <tkient...@apple.com <mailto:tkient...@apple.com>> 写道：
> If you’re interested in protobuf support for Swift, you might want to take a
> look at the protoc p
there
is 0x12 = 2 * 8 + 2).
Your C++ code thinks the `wiffName` field is field #3 (the third byte is
0x1a = 3 * 8 + 2).
Also, both are correctly writing UTF-8 strings into the output.
Tim
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers"
I am trying to section up my protocol buffers into simpler or digestable
files (each file fitting a category like device and all messages that would
make up a device. I then want to import that into my main pb definition
file. I do it, I compile it and there is a reference to the object (test
37 matches
Mail list logo
