nd 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
n can use the ATTR1_BIT definitions to implement it
own tracking of message field characteristics.
Does that change anything?
Tim
On Feb 23, 7:18 pm, Kenton Varda wrote:
> Hi Tim,
>
> On Mon, Feb 23, 2009 at 7:01 PM, wrote:
>
> > In my application, I have a need to track cha
ort MyObjectClassCode
from other files.
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
--~--~
#x27;t see any indication of this.
Also, Is anyone else using PB in this way?
Tim
On Feb 23, 1:33 pm, Joshua Haberman wrote:
> On Feb 23, 9:51 am, Caleb wrote:
>
>
>
> > On Feb 6, 5:56 pm, Joshua Haberman wrote:
> > > Does proto2 support event-based decoding
Anyone out there using GPB on an OS other than Linux or Windows? I've
been evaluating GPB for use in an embedded OS and at the moment am a
bit stuck between protobuf and protobuf-c. We would be using GPB for
simple data storage and serialization, and don't need RPC or even
Reflection. I checked ou
terribly
> different from Linux. The Google implementations 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-dow
code that only implements this new "lean" interface. Hopefully this
> new library would be far smaller than the current 870k libprotobuf.so.
>
> On Fri, Feb 27, 2009 at 10:58 AM, Tim wrote:
>
> > That's precisely the case I've been hoping to make in my c
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
sage field would be managed 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
--~--~-~--~~~---~--~-
r enums 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.
T
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 src/.libs
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
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
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 to
s a protobuf 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 thi
these
proto-format names.
Cheers,
Tim
P.S. I think using JSON-format names in FieldMask was a mistake;
practically speaking, generated code has to embed raw proto-format names
anyway, so JSON FieldMask could have carried proto-format names and you
would have avoided an entire class of round
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
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 {
requi
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;
r
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 f
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 wrote:
>
> Hi Tim,
>
> I think your analysis is correct. The answer to your question is t
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,
>>
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 ri
> On Mar 14, 2016, at 11:50 AM, Feng Xiao wrote:
>
>
>
> On Thu, Mar 3, 2016 at 6:37 PM, Tim Kientzle wrote:
>
> I think your current Any JSON design requires that protobuf serialization be
> able to fail. This is definitely a major change from proto2 and something
osed 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 policies.
Tim
--
Yo
e 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 receiving em
> On Mar 17, 2016, at 10:04 AM, Feng Xiao wrote:
>
> On Wed, Mar 16, 2016 at 7:49 PM, Tim Kientzle wrote:
>
> > On Mar 14, 2016, at 7:07 PM, Feng Xiao wrote:
> >
> > In google, we are using a front-end proxy to convert JSON to/from protobuf,
> > an
l-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 to the Google Groups
"Prot
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 wrote:
>
> Big fan of 4, 5, 6, and 7. Huge un-fan of 2, and 3. I am mixed on 1 because I
> love the removal
o2. 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+unsubscr...@googlegroups.co
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"
s.google.com/protocol-buffers/docs/reference/other
Tim
>
> thanks!
>
> 2016年9月23日星期五， mailto:tkient...@apple.com>> 写道：
> If you’re interested in protobuf support for Swift, you might want to take a
> look at the protoc plugin that Apple just open-sourced.
>
>
> 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
"Protocol
tion?
You want to use the well-known types “Struct” or “Value”, which are
specifically designed to support ad hoc JSON parsing. “Struct” supports
parsing any valid JSON object structure, “Value” can parse any valid JSON:
message User {
string email = 1;
string firstName = 2;
string lastNa
I think we need more details:
Are you using C++ or Java or Python or Ruby or C# or some other language?
What version of protoc?
Can you show the code you’re using to create the message?
Tim
> On Nov 16, 2016, at 5:02 AM, Bojan D wrote:
>
> Thanks for the answer. Somehow
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" group.
To unsubscribe from this group
x27;.
>
> 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 re
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 wou
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 of
I'm trying to minimize the code size of the protocol buffers. I've
enabled Lite Runtime, but I'd like to reduce it further. There are
several protocol buffers that I am not using which I would like to
conditionally compile out. Is there a way to do this?
I have been able to remove the protobufs
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 su
x27;t 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
pr
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 t
44 matches
Mail list logo
