ailable through vcpkg as
well, giving you a consistent process for third party libraries...
Stuart Dootson
On 29 January 2018 at 11:59, 'Frank Willen' via Protocol Buffers <
protobuf@googlegroups.com> wrote:
> Hi Marc,
>
> many thanks for your reply. I already found the vers
ons not to be. The
light frameworks provide those reasons.
Marc
On 8 June 2010 20:33, Stuart <mailto:stu...@stu.org.uk>> wrote:
If I use the -p:lightFramework option on protogen.exe, does anything
important get left out for use on the full framework?
--
You rec
If I use the -p:lightFramework option on protogen.exe, does anything
important get left out for use on the full framework?
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To uns
If a new enum value had been added to a enum type, and it's being
deserialised by an application that is not yet aware of the new enum
value, what should happen?
Should the enum value be null, or should the deserialisation abort?
--~--~-~--~~~---~--~~
You recei
It's a good idea to send a delimiter as well, even if your end-to-end
communication is considered reliable (TCP). A software bug at ether end
could cause you to loose sync.
Use one byte as your "Start Byte" (0xaa for example) followed by the
length of your message (can be a compressed integer)
compiler will build that for me.
Stuart.
--~--~-~--~~~---~--~~
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 t
I would like an efficient way of describing which message is being sent in a
stream. Using a string name (as used in Protobuf rpc), is less efficient than a
numeric value.
All fields have a unique numeric key, so how about messages also having a
(optional) numeric key also? Then the PB compil
I have been thinking about the most efficient way of describing which
message is being sent in a stream. All fields have a numeric key, so
how about messages also having a (optional) numeric key too? Then the
PB compiler could populate a global enumerator list of messages, which
you could u
uld be enough.
>
> Please give us feedback if you don't (or do) like the solution.
>
> /Magnus
>
>
> -Original Message-
> From: protobuf@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Stuart
> Sent: den 17 november 2008 16:23
> To: Protocol Buff
I have a c# server application with miltiple clients. I want to
replace the existing protocol with PB.
The clients connect, and remain connected prediodically passing data
of differnet types.
I have searched the discusstion group, and found a few postings
relating to this issue, but nothing fin
10 matches
Mail list logo
