Re: [protobuf] Distributing protobuf library and protos in a plug-in framework
On Tue, Apr 28, 2015 at 10:39 PM, elodg wrote: > Thanks, Feng. One more thing: lite_runtime is not supported in proto3 > alpha 1. Is it going to stay this way? > The first proto3 release (official 3.0) will not have lite runtime support. We plan to add it after the first release. > Is the runtime for proto3 going to be smaller than for proto2, thus no > need for lite? > No, proto3 uses the same runtime as proto2 for C++. It will only be larger. We didn't add lite-runtime support in order to make things simpler for the initial release. > > On Tuesday, April 28, 2015 at 11:50:41 PM UTC+3, Feng Xiao wrote: > >> >> >> On Mon, Apr 27, 2015 at 11:54 PM, elodg wrote: >> >>> I provide pure virtual interfaces and abstract default implementations >>> in header-only source code specifically to allow for different compilers >>> and compiler settings. It seems to me that I either have to provide pb.cc >>> and the protobuf lib source, or just .protos and let developers download, >>> compile and statically link protobuf into the plug-in. >>> >> That's what I think as well. >> >> >>> Is there a subset of protobuf source I could provide? Sort of like bcp >>> for boost? >>> >> We don't have such tools. I think you can use LITE_RUNTIME to generate >> the pb.cc/pb.h file and only include the protobuf-lite part of the >> source. >> >> >>> >>> On Monday, April 27, 2015 at 11:11:03 PM UTC+3, Feng Xiao wrote: On Mon, Apr 27, 2015 at 11:04 AM, elodg wrote: > Suppose there is a plug-in framework that uses protobuf to pass data > around between plug-ins. The plug-ins can be C++ dynamic libraries, where > the proto wire crosses the ABI boundary going around binary > incompatibilities. Many different predefined protos exist that need to be > distributed to plug-in developers. > I think I am correct in saying that since there is no guarantee of ABI > compatibility, each plug-in dll will need to compile and statically link > protobuf. The question is how is the library and protos meant to be > distributed? Do I provide .protos and let plug-in developers download > protobuf and compile everything? Do I provide pb.c/h and protobuf library > sources? > Besides these protos, what else do you provide for plug-in developers to code against your framework? Do you provide a static library or put everything as source code? If you provide a static library for plug-in developers to link with, I think you can have the generated .pb.cc files compiled in the static library and include .pb.h in the public header files for plugin developers to use. > > -- > 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+u...@googlegroups.com. > To post to this group, send email to prot...@googlegroups.com. > Visit this group at http://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- >>> 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+u...@googlegroups.com. >>> To post to this group, send email to prot...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/protobuf. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 http://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- 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 http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
I am also evaluating proto2 vs proto3 and even though it seems proto3
should be the way to go I really miss the has_** functionality in proto3.
It seems the following proto pattern may be a workaround:
message M{
oneof optional_value{
int32 value = 1;
}
}
It does generate value(), set_value(), clear_value() and has_value()
methods (C++) but unfortunately the has_value is private.
Is there a reason such a useful and short method is declared private (it
implementation only uses public functionality as well)
On Wednesday, February 11, 2015 at 3:55:03 PM UTC-5, Alfred Kwan wrote:
>
> Thanks for pointing me to "oneof". I gave it a try and I have two
> questions:
> 1) I see the has_() being generated for all the fields inside oneof. Is
> this kind of has_() function here to stay throughout subsequent V3 releases?
> 2) Since oneof does not allow a repeated field in both V2/3, is there
> pro/cons in case I create one extra layer of structure i.e.:
> message manyMsg{ // workaround: wrap the repeating message
>repeated oneMsg = 1;
> }
> message unionMsg{
>oneof testOneof{
> manyMsg msg = 1; // doesn't allow repeated
> uint32 foo = 2;
>}
> }
>
>
>
> On Sunday, February 8, 2015 at 11:01:04 PM UTC-5, Feng Xiao wrote:
>>
>> The union types are obsoleted by oneof:
>> https://developers.google.com/protocol-buffers/docs/proto#oneof
>>
>> On Sat, Feb 7, 2015 at 4:53 AM, Alfred Kwan wrote:
>>
>>> To implement the has_boo() in 3.0 implies one boolean per each truly
>>> optional field, which means additional maintenance is now required, e.g.
>>> matching naming scheme for the pool together with the optional struct, also
>>> should we group all booleans together or should they sit right next to the
>>> to corresponding optional structures...
>>>
>>> With the uncertainty of how "any" replaces "extensions" plus the removal
>>> of has_boo(), it seems like new adopters (I'm one of them) should pick V2
>>> over 3.0.
>>>
>>> On Wednesday, January 28, 2015 at 3:10:39 PM UTC-5, Feng Xiao wrote:
On Wed Jan 28 2015 at 12:06:21 PM Troy Lee wrote:
> Feng,
>
> Version 3 removes presence logic.
> How do we exam whether a field is exist or not?
>
This is no possible for singular primitive fields. For singular message
fields, the has methods will still be generated. Basically with proto3
you'll need to write your code without depending on these dropped
features.
It's believed that most users don't use the field presence logic much and
for those who need this feature adding a bool field is an easy workaround.
>
> Thanks,
> troylee
>
> Feng Xiao於 2014年12月11日星期四 UTC+8下午12時51分01秒寫道：
>
>> Hi all,
>>
>> I just published protobuf v3.0.0-alpha-1 on our github site:
>> https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1
>>
>> This is the first alpha release of protobuf v3.0.0. In protobuf
>> v3.0.0, we will add a new protobuf language version (aka proto3) and
>> support a wider range of programming languages (to name a few: ruby,
>> php,
>> node.js, objective-c). This alpha version contains C++ and Java
>> implementation with partial proto3 support (see below for details). In
>> future releases we will add support for more programming languages and
>> implement the full proto3 feature set. Besides proto3, this alpha
>> version
>> also includes two other new features: map fields and arena allocation.
>> They
>> are implemented for both proto3 and the old protobuf language version
>> (aka
>> proto2).
>>
>> We are currently working on the documentation of these new features
>> and when it's ready it will be updated to our protobuf developer
>> guide .
>> For the time being if you have any questions regarding proto3 or other
>> new
>> features, please post your question in the discussion group.
>>
>> CHANGS
>> ===
>> Version 3.0.0-alpha-1 (C++/Java):
>>
>> General
>> * Introduced Protocol Buffers language version 3 (aka proto3).
>>
>> When protobuf was initially opensourced it implemented Protocol
>> Buffers
>> language version 2 (aka proto2), which is why the version number
>> started from v2.0.0. From v3.0.0, a new language version (proto3)
>> is
>> introduced while the old version (proto2) will continue to be
>> supported.
>>
>> The main intent of introducing proto3 is to clean up protobuf
>> before
>> pushing the language as the foundation of Google's new API
>> platform.
>> In proto3, the language is simplified, both for ease of use and
>> to
>> make it available in a wider range of programming languages. At
>> the
>> same time a few feature
Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
On Wed, Apr 29, 2015 at 6:21 AM, Nikolay Mladenov <
nikolay.mlade...@gmail.com> wrote:
> I am also evaluating proto2 vs proto3 and even though it seems proto3
> should be the way to go I really miss the has_** functionality in proto3.
>
> It seems the following proto pattern may be a workaround:
>
> message M{
>oneof optional_value{
> int32 value = 1;
>}
> }
>
> It does generate value(), set_value(), clear_value() and has_value()
> methods (C++) but unfortunately the has_value is private.
> Is there a reason such a useful and short method is declared private (it
> implementation only uses public functionality as well)
>
You can use "optoinal_value_case()" to check which oneof is set.
>
>
>
>
> On Wednesday, February 11, 2015 at 3:55:03 PM UTC-5, Alfred Kwan wrote:
>>
>> Thanks for pointing me to "oneof". I gave it a try and I have two
>> questions:
>> 1) I see the has_() being generated for all the fields inside oneof. Is
>> this kind of has_() function here to stay throughout subsequent V3 releases?
>> 2) Since oneof does not allow a repeated field in both V2/3, is there
>> pro/cons in case I create one extra layer of structure i.e.:
>> message manyMsg{ // workaround: wrap the repeating message
>>repeated oneMsg = 1;
>> }
>> message unionMsg{
>>oneof testOneof{
>> manyMsg msg = 1; // doesn't allow repeated
>> uint32 foo = 2;
>>}
>> }
>>
>>
>>
>> On Sunday, February 8, 2015 at 11:01:04 PM UTC-5, Feng Xiao wrote:
>>>
>>> The union types are obsoleted by oneof:
>>> https://developers.google.com/protocol-buffers/docs/proto#oneof
>>>
>>> On Sat, Feb 7, 2015 at 4:53 AM, Alfred Kwan wrote:
>>>
To implement the has_boo() in 3.0 implies one boolean per each truly
optional field, which means additional maintenance is now required, e.g.
matching naming scheme for the pool together with the optional struct, also
should we group all booleans together or should they sit right next to the
to corresponding optional structures...
With the uncertainty of how "any" replaces "extensions" plus the
removal of has_boo(), it seems like new adopters (I'm one of them) should
pick V2 over 3.0.
On Wednesday, January 28, 2015 at 3:10:39 PM UTC-5, Feng Xiao wrote:
>
>
>
> On Wed Jan 28 2015 at 12:06:21 PM Troy Lee wrote:
>
>> Feng,
>>
>> Version 3 removes presence logic.
>> How do we exam whether a field is exist or not?
>>
> This is no possible for singular primitive fields. For singular
> message fields, the has methods will still be generated. Basically with
> proto3 you'll need to write your code without depending on these dropped
> features. It's believed that most users don't use the field presence logic
> much and for those who need this feature adding a bool field is an easy
> workaround.
>
>
>>
>> Thanks,
>> troylee
>>
>> Feng Xiao於 2014年12月11日星期四 UTC+8下午12時51分01秒寫道：
>>
>>> Hi all,
>>>
>>> I just published protobuf v3.0.0-alpha-1 on our github site:
>>> https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1
>>>
>>> This is the first alpha release of protobuf v3.0.0. In protobuf
>>> v3.0.0, we will add a new protobuf language version (aka proto3) and
>>> support a wider range of programming languages (to name a few: ruby,
>>> php,
>>> node.js, objective-c). This alpha version contains C++ and Java
>>> implementation with partial proto3 support (see below for details). In
>>> future releases we will add support for more programming languages and
>>> implement the full proto3 feature set. Besides proto3, this alpha
>>> version
>>> also includes two other new features: map fields and arena allocation.
>>> They
>>> are implemented for both proto3 and the old protobuf language version
>>> (aka
>>> proto2).
>>>
>>> We are currently working on the documentation of these new features
>>> and when it's ready it will be updated to our protobuf developer
>>> guide .
>>> For the time being if you have any questions regarding proto3 or other
>>> new
>>> features, please post your question in the discussion group.
>>>
>>> CHANGS
>>> ===
>>> Version 3.0.0-alpha-1 (C++/Java):
>>>
>>> General
>>> * Introduced Protocol Buffers language version 3 (aka proto3).
>>>
>>> When protobuf was initially opensourced it implemented Protocol
>>> Buffers
>>> language version 2 (aka proto2), which is why the version number
>>> started from v2.0.0. From v3.0.0, a new language version
>>> (proto3) is
>>> introduced while the old version (proto2) will continue to be
>>> supported.
>>>
>>> The main intent of introducing proto3 is to clean up protobuf
>>> before
>>> pushing the language as th
