As yet, there is no single common RPC standard for use with protobuf.
Protobuf-net hacks itself into WCF by swapping out some WCF guts, but while
that will work with WCF-to-WCF it won't make sense to flex. That is why I
suggested just sending a byte-array, since this is easily represented by
That all depends on how ProtoBuf-Actionscript encodes the payload. I know
nothing about that, so can't really comment.
On 24 November 2010 19:28, mvbaffa mvba...@gmail.com wrote:
pposed I could send information from Flex using ProtoBuf-
Actionscript
--
Regards,
Marc
--
You received
or TCPBinding ???
Thanks again,
On Nov 24, 9:50 pm, Marc Gravell marc.grav...@gmail.com wrote:
That all depends on how ProtoBuf-Actionscript encodes the payload. I
know
nothing about that, so can't really comment.
On 24 November 2010 19:28, mvbaffa mvba...@gmail.com wrote:
pposed I could send
use it *without* .proto, as I am
usually just talking .NET to .NET, and I just want to serialize stuff.
Jon may be offer to give more specific pointers about his version.
Marc Gravell
On 9 December 2010 14:06, vinu vinodkumara...@gmail.com wrote:
Sir,
Any body please send me any example
Yes; *at the moment* I don't make that search path very accessible. When I
have the lid up I'll look at that, but for now if you really need to handle
a complex include path, there is an ugly workaround... and not via the IDE
tools (only at the command line).
Marc
On 13 December 2010 22:18, Thad
Are you using the IDE or command-line to handle the .proto? There is a switch
for this - I'm not at a PC at the moment, but try protogen /?
I'll be at a PC in a few hours; I should be able to give a more complete answer
then. If using the IDE there is a trick here involving the namespace
18:05, Marc Gravell marc.grav...@gmail.com wrote:
Are you using the IDE or command-line to handle the .proto? There is a
switch for this - I'm not at a PC at the moment, but try protogen /?
I'll be at a PC in a few hours; I should be able to give a more complete
answer then. If using the IDE
the appropriate flags accordingly?
Many thanks for your help,
Andrew
On 6 January 2011 20:50, Marc Gravell marc.grav...@gmail.com wrote:
I've dug out the syntax; in the namespace box, you *can* enter a regular
namespace, and that will be used for the *generated codes* namespace,
however **after
maybe I'm being slow (it is late here), but what would 126 look like?
You could say ah, pad to the expected length, but then -1 is encoded as
1110 - and as I see it, *that* is
what zip-zag attempts to avoid.
It also solves the problem of switching from 32 to
Hmmm - good question. A bit of an edge case, really, deserializing over the
top of an existing byte[], or having duplicated byte[]. But thinking about
it, it probably should adhere to the singular scalar fields logic and
replace rather than accumulate.
I'll log that as a bug. Out of curiosity, is
I assume you mean with protobuf-net there; in which case, no.
Because protobuf-net follows the general protobuf spec, there is no
type-specific metadata that would allow me to encode/decode an arbitrary
object, or to store the details of which type of object is stored.
Marc (protobuf-net)
On 29
field.
Cheers,
Richard
*From:* Marc Gravell [mailto:marc.grav...@gmail.com]
*Sent:* 31 January 2011 01:04
*To:* NYCBrit
*Cc:* Protocol Buffers
*Subject:* Re: [protobuf] Why does protobuf-net append to a byte[]
Property/field on deserialize?
Hmmm - good question. A bit of an edge
Yes, that is already on my list of things I really, really want it to do. It
will inevitably be in v2 at some point, but to repeat your point: this
will be 100% implementation specific and not generically portable between
platforms, so it will have to be by explicit opt in.
Marc
On 1 February
!
*From:* Marc Gravell [mailto:marc.grav...@gmail.com]
*Sent:* 31 January 2011 01:06
*To:* NYCBrit
*Cc:* Protocol Buffers
*Subject:* Re: [protobuf] Serializing Dictionarystring,object
I assume you mean with protobuf-net there; in which case, no.
Because protobuf-net follows
Nice - I'm glad that was a v2 patch, though ;p
Before I look at that at any length, though, can you confirm that you can
freely release this patch under the existing license terms? (just my CYA)
Marc
On 1 February 2011 03:03, NYCBrit tristra...@googlemail.com wrote:
I've made a small
I think this also came to me directly and I answered earlier, but this is the
expected layout of repeated data, where each item in a list is mapped
separately in the data stream.
Marc
On 1 Feb 2011, at 11:01, Timothy Parez timothypa...@gmail.com wrote:
Hello,
Considering the following
For info (not from me) -
http://stackoverflow.com/questions/5110594/protobuf-nested-message-parsing-not-working
(I try to watch the protobuf tags on SO,but that is far outside of my
little corner of protobufs)
Marc
--
You received this message because you are subscribed to the Google Groups
I really think that would make more sense with an example...
re 1; if you attempt to process data that isn't of the correct format, you
should expect it to blow up - the same as a json serializer would blow up if
you fed it xml; you can, however, pack arbitrary byte[] data *inside* a
protobuf
(resend; forgot to copy the group)
I have a somewhat cavalier approach, do I *do* support that in my
implementation, but that is because my main audience is retrofitting to
existing classes, or code-first; not contract first.
I won't get into a snare about whether that is right or wrong, but
There is no checksum in a protobuf stream. You would need to add something
external.
On 29 March 2011 22:14, Tavis Bones tavis.bo...@gmail.com wrote:
Internally does protocol buffers use a checksum to guarantee the data
being read/written?
If not, do I need to write the checksum like the
You mean this?
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
The zero is not a tag / field-number; it is just an enum value. The 2 on the
last line I've copied is a
, Marc Gravell marc.grav...@gmail.com wrote:
You mean this?
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
The zero is not a tag / field-number
I'm doing some code maintenance on my protobuf library, and I have
encountered a test that is... confusing me. So before I go crazy (/
crazier)... what should an implementation do if during deserialization
it gets an enum it doesn't recognise?
- to explode in sparks?
- to ignore the data?
- to
It sounds to me like you are over-complicating things. It is not uncommon to
have a separate DTO model for serialization, so simply write a little code to
map from your domain model (the comple model described above) to the DTO model
(close to the serialization format).
It is possible to write
The code shown uses XmlSerializer - it doesn't use protobuf-net at all.
protobuf-net does tend to be friendly towards this, however you would:
- deserialize with protobuf-net into objects
- serialize with XmlSerializer
The only point of co tact between the two is the object model in the middle.
Right; what platform are you on? That approach is certainly viable - it is in
fact how protobuf-net operates (via .NET attributes).
In guessing you are on Java; I do not know of a similar Java implementation.
Marc
On 29 Jun 2011, at 03:55, ordinary tao.ordin...@gmail.com wrote:
Coding use
I am not able to advise on either C++ option. However, if your solution doesn't
already use .NET I wouldn't introduce a .NET dependency just for this - just
use the c++ version.
If your solution already contains some .NET classes and your intention is to
add some protobuf, then it perhaps is
I don't pretend to know the original thinking, but it would be very hard to add
such now without breaking existing clients. However, note that if you *really*
don't want to have to get the lengths, you could encode your data inside a
group, since this has a terminator rather than a length
I haven't used protostuff/IKVM, but I would *hope* that IKVM allows some kind
of passing of either a Stream or byte[]. That would allow you to
serialize/deserialize to swap between models.
If you have access to *both* models at once, perhaps another possibility is
AutoMapper on the .NET side.
Golden rule:
- don't change a field, or re-use a field-numer
In particular, your string vs int *is* a breaking change. Most of the others
are not; additional data can be ignored or handed at runtime via extensions if
you wish. Of course, if you add a new field you should probably make it
If I understand the meaning, then I would tend to make the exception
scenario mean something is fundamentally wrong with the service, rather
than your request was invalid. The latter scenario is better handled by
allow an error message as part of the standard API - which could be anything
from a
/msgpack/browse_thread/thread/db5e20aa64f3020d?pli=1
Marc Gravell
On 2 August 2011 08:51, Canggih Wibowo cangca...@gmail.com wrote:
MessagePack claims that they 4 times faster than Protobuf on
serialization+deserialization and it also have RPC implementation already.
Anyone give response? I mean
, Marc Gravell marc.grav...@gmail.comwrote:
It is a pain that it is so hard to set up a Custom Tool in VS; I do
have a custom tool working for protobuf-net, but it is annoying to have to
install it manually (there's a download on the protobuf-net site). I pinged
the nuget team to see if we can get
This will depend on many factors:
- how big is each fragment? Very small fragments of *anything* generally get
bigger when compressed
- what is the data? If it contains a lot of text data you might see benefits;
however, many typical fragments will get bigger when compressed - it depends
Protocol buffers works best with structured and predictable data. object
sounds overly vague IMO. Most protocol buffers will not handle that; due to
demand, I *do* have a feature in protobuf-net that might work for that, but it
basically breaks all the interop benefits of protocol buffers. So
Ooh, that sounds like me, then. It works fine against the current v2 code; I
do seem to recall there was a bug at some point in v2 that behaved like
this. If you are using v2, please make sure you have a recent version. If
you are using v1 and this happens /there/, then my flabber is officially
Protocol buffers itself only (AFAIK) describes the serialisation format; it
does not define RPC. If you add an http-based RPC stack, then it will be
http-based, but that is nothing to do with protocol buffers, you could (and
many do) use raw sockets just as well.
Marc
On 30 Sep 2011, at
I answered this where you cross-posted on stackoverflow:
http://stackoverflow.com/questions/7717036/serialize-protocol-buffer-file-into-xml-text-format
To repeat; in most cases, the generated code **should already** work
perfectly well with XmlSerailizer (the inbuilt .NET xml serialization tool),
In standard use, protouf-net is fully contract based and doesn't care what
*types* are involved; this only matters if you are using the DynamicType option
(which is outside the core protobuf stuff). If the types aren't stable, there
is an event on the TypeModel that can be used to map in both
In the next build, this has been tweaked:
type = source.DeserializeType(typeName);
if(type == null)
{
throw new ProtoException(Unable to
resolve type: + typeName);
}
So,
Addressed on stackoverflow:
http://stackoverflow.com/questions/7793527/protobuf-net-serializing-ienumerablet
Marc
On 17 Oct 2011, at 12:35, Broken Pipe brokenpipe.co...@gmail.com wrote:
I'm trying to use ProtoBuf-net in Silverlight project, I'm using my
existing domain objects, which define
Well, firstly protobuf is not a text format, so UTF-8 is not the way to start.
What is it you need? Note that the protobuf format is ambiguous unless you
already know the schema (the same data can be interpreted in different ways).
However, if you read the encoding spec, you should be able to
at 11:02 AM, Marc Gravell marc.grav...@gmail.com
wrote:
Well, firstly protobuf is not a text format, so UTF-8 is not the way to
start. What is it you need? Note that the protobuf format is ambiguous
unless you already know the schema (the same data can be interpreted in
different ways). However
Inside any standard implementation? None. And I doubt that is something that
would be added anytime soon (if ever). You could of corse create some private
branch combining elements of protobuf with your own more specific needs.
Marc
On 20 Oct 2011, at 12:32, Phillip Dann Ward
that could also just mean stable and not needing massive work - there
haven't been any significant changes to the protobuf format since packed
arrays (the most recent commit).
(I honestly don't know either way; I just don't think it is quite safe to
assume lack of activity means abandoned here)
@Bob - based on the version numbers, Yury is talking about protobuf-net
(one of the 3rd party .NET implementations), using it on iOS via MonoTouch
or Unity
@Yury - sorry, I completely didn't see this thread; but indeed, the iOS
folder got accidentally dropped when I updated my build script, and
a copy of the current
code compiled with FEAT_SAFE?
Marc Gravell
(protobuf-net)
On 19 December 2011 19:11, Scott Moore scott.moor...@gmail.com wrote:
I readily admit that I am a bit of a novice developer (I work in a
small business and we all help as much as possible). I came across
If you mean protobuf-remote (which I'm not personally familiar with),
that is an RPC stack. It will help you send and receive messages. Any
database requirements you must handle separately. There is a manual
page linked for both C# and C++ - http://code.google.com/p/protobuf-remote/
Marc
On Dec
Well, protobuf-net certainly includes them (it just does a simple UTF-8
conversion, nothing more), and I'm pretty sure the C++ side will be
handling them fine.
My guess would be that they are being lost in your code with whatever file
/ network handling you have in place. In particular, any code
Sorry, I didn't see this at the time - do you have any kind of concrete,
reproducible example here?
Marc
On 28 February 2012 20:48, costa costa.ba...@gmail.com wrote:
Have you seen this?
The list is an IListTestClass where TestClass has the ProtoContract
attribute and all its members have
it only has to be unique to the particular message - not unique globally.
The why is simply: because that is what it uses on the wire to identify
different members.
If they weren't unique, clearly it wouldn't work. If they weren't explicit
(but were, say, assumed positionally) then it would not
was complaining
about shared ids. [?]
On Mon, Jun 4, 2012 at 11:44 AM, Marc Gravell marc.grav...@gmail.comwrote:
it only has to be unique to the particular message - not unique globally.
The why is simply: because that is what it uses on the wire to identify
different members.
If they weren't unique
This relates to protobuf-net; you've already emailed me directly, and I
replied. You raised an issue report: I replied. Please read (and act on) my
existing replies.
Marc
On 4 Jun 2012, at 12:00, Farooq Mushtaq farooqmushta...@gmail.com wrote:
While serializing I am getting error Possible
I answered this at stackoverflow (http://stackoverflow.com/a/11083229/23354)
The main problem was the data-types in V3DDelta not matching the contract
(note: there are tools for generating classes from a .proto definition).
The particular code for reading the data stored via writeDelimitedTo
(note: this is specific to protobuf-net, not protocol buffers more
widely), but yes: that (a generic list) would work fine, as long as the
property has been marked for serialization and given a number. There also
doesn't need to be a set accessor, although it can make full use of a
set - i.e. if
On Wednesday, June 20, 2012 9:05:49 AM UTC-4, Marc Gravell wrote:
(note: this is specific to protobuf-net, not protocol buffers more
widely), but yes: that (a generic list) would work fine, as long as the
property has been marked for serialization and given a number. There also
doesn't need to be a set
to this stuff, so if I'm not making any sense at all let me
know and I'll return with a smarter question.)
Joel
On Wednesday, June 27, 2012 4:07:49 PM UTC-4, Marc Gravell wrote:
The data is of course compatible. A `ListFoo` is directly mappable to
.proto via for example:
message
June 2012 13:51, Joel Carrier j...@joelcarrier.com wrote:
Yes it does. Thanks.
Where can I read more about this disabling of list-handling and its
effects?
On Thu, Jun 28, 2012 at 8:31 AM, Marc Gravell marc.grav...@gmail.comwrote:
Well, until I get around to re-implementing it for v2
protobuf-net indeed needs *some* way to associate protobuf numbers with
members; one of the ways it supports is `[XmlElement(Order=n)]`, but to
confirm: yes the n needs to be = 1, and yes, since `[XmlAttribute]`
doesn't specify any such number, protobuf-net can't use that in any
meaningful way.
And in this model, what is FloatData, StringData, IntData, etc?
This is certainly solvable with protobuf-net, but to do a complete example
I'd need to see those additional types.
Marc
(protobuf-net)
On 31 July 2012 14:14, Shail shailendranalw...@gmail.com wrote:
public class Param
{
System.Single[] Values;
}
Regards
Shailendra
On Wednesday, 1 August 2012 11:51:01 UTC+5:30, Marc Gravell wrote:
And in this model, what is FloatData, StringData, IntData, etc?
This is certainly solvable with protobuf-net, but to do a complete
example I'd need to see those additional
AdjustValue;
/// remarks/
[System.Xml.Serialization.**XmlAttributeAttribute()]
public System.Single[] Values;
}
Regards
Shailendra
On Wednesday, 1 August 2012 11:51:01 UTC+5:30, Marc Gravell wrote:
And in this model, what is FloatData, StringData, IntData, etc
This sounds very protobuf-net specific; it might be easier to take this
off-group, but I think I'll need a bit more context; in particular, since it is
a PCL type, what runtime is this on when erroring? Also, are you using
Serializer.*, or are you creating an instance of the custom serializer
Hi again. I already replied with a few comments / questions on stack overflow.
I'm happy to try to help, but at the moment you haven't given me much context
to work on.
Marc
(protobuf-net)
On 7 Dec 2012, at 11:28, Evangelist murali.po...@gmail.com wrote:
Hello folks,
I have a wcf service
this seems to be a resurrection of a protobuf-net specific discussion, so
let me jump in...
The SerializeWithLengthPrefix method, by default, aims to represent data in
a way that is a valid protobuf stream - in particular, as though it were
simply a member of a parent object or list. As such, it
Sorry - intended to cc the list for reference purposes
---
This is protobuf-net specific; sorry for delay bit I'm on a family weekend
and my wife deliberately picks destinations far far away from cell towers.
To explain: protobuf-net always starts from
, Unsupported Message Type: + _type);
}
Thank you all for helping out... :)
On Saturday, March 23, 2013 1:35:27 PM UTC-5, Marc Gravell wrote:
Protobuf-net does not swallow any errors - if bad things happen in
shouts loudly. Additionally the API is thread safe - during deserialization
The outermost message is not stored with a length; this allows multiple
messages to be merged by concatenation. The default behaviour for a protobuf
parser at the root-object is read until you run out of data. If you have
written multiple messages without some kind of framing (usually adding
On 7 May 2013 19:40, Marc Gravell marc.grav...@gmail.com wrote:
I don't know about the other stuff. But: protobuf does not include any
form of encryption. Since it only handles serialization (not full RPC) it
does not include any authentication logic either. The data is serialized
without
On 7 May 2013 18:53, Marc Gravell marc.grav...@gmail.com wrote:
Protobuf has a fee encodings for integer data, which basically come down
to:
- varint (with or without zigzag)
- fixed-32 (always 4 bytes)
- fixed-64 (always 8 bytes)
For 16 bits, you will do best with varint. If the data can
headerMsgLenMsgheaderMsgLenMsg... is the standard form of
protobuf repeated data. A header value of 10 is the standard form for a
length-prefixed field with key 1. If you want to read all the objects
together, then write a wrapper message, i.e.
message animals {
repeated animal items = 1;
}
I asked about this a few years ago (feel free to search the archive - I
couldn't find it; I believe I used the term subnormal forms for this).
IIRC the answer then was along the lines of hmmm looking at the
current implementation that will probably work, but it isn't guaranteed and
won't be
interest to me, since I don't use the Google API).
Marc
On 14 May 2013 17:47, Marc Gravell marc.grav...@gmail.com wrote:
I asked about this a few years ago (feel free to search the archive - I
couldn't find it; I believe I used the term subnormal forms for this).
IIRC the answer then was along
think it is more of a bug in the protoc implementation that it fail's
to parse such a message.
Kind regards,
Jonas
On Tuesday, May 14, 2013 6:50:00 PM UTC+2, Marc Gravell wrote:
I should clarify: when talking about groups I should emphasise that
Google have marked that feature plagued. Which
have any plan to change it.
As to your performance concern, only benchmarks can tell. So far I haven't
seen such data showing that prefixing a fixed-size length is a performance
gain.
Kind regards,
Jonas
On Tuesday, May 14, 2013 6:50:00 PM UTC+2, Marc Gravell wrote:
I should clarify
I don't know about project/product lists, but you could look to
https://code.google.com/p/protobuf/downloads/list - 50,000 downloads of
protoc 2.5 since late February, which suggests reasonable usage - and that
doesn't include packages that either don't use protoc, or which embed
protoc. You could
This is a protobuf-net specific question. The answer to that depends on
what you want to do. And I should stress that using attribute decoration is
a lot simpler (and is what you get if you start from .proto). But basically:
RuntimeTypeModel.Default
.Add(type(Customer), false)
There is nothing UB the specification to enforce that. You would have to
use your own checks.
On 11 Jun 2013 01:55, oxlc li.c...@openx.com wrote:
Hi everyone,
Through some quick searching I couldn't find any discussion about
specifying a repeated field that must have at least one of them in a
Protocol buffers is language and platform independent, so yes: you can
share data happily without worrying about what each is.
However, it is a serialisation layer *only*. It does not include RPC etc.
If you want to get data from a to b, it is fine. Anything to do with
relaying function calls you
Have you looked through the examples on the protobuf project site?
On 13 Jun 2013 18:09, Genius genius.b...@gmail.com wrote:
I want to use protocol buffer files.
I am trying to build schema and I have data of various types like int,
string, byte.
so to declare the byte data of 4 bytes how do
Hi - you also asked this on stackoverflow, and I asked you a few questions
- can you answer them? Ta
http://stackoverflow.com/questions/17173588/protobuf-wcf-no-model-instance-has-been-assigned
Marc
On 19 Jun 2013 21:59, Andrew McCormack mccor...@gmail.com wrote:
I am getting this error:
No
This is specifically a protobuf-net question.
In short, yes - that is fine... ish. If you add the numbers manually ***and
get them right***, then it will work. However, your example actually gets
them wrong: the protobuf-net library specifically assumes an *alphabetical*
order for the properties
,
this would be a good choice) but the above is much easier for ad-hoc
scenarios.
Marc
(protobuf-net)
On 15 July 2013 19:48, Marc Gravell marc.grav...@gmail.com wrote:
This is specifically a protobuf-net question.
In short, yes - that is fine... ish. If you add the numbers manually
***and get them
Protobuf supports recursive schemes - but note that each object is separate (it
is a tree, not a graph). For example, descriptor.proto includes the
self-referential DescriptorProto (which is a message in language terms)
// Describes a message type.
message DescriptorProto {
optional string
This is specifically a protobuf-net question. I am guessing that somewhere
in your model is a property / field declared simply as object. That isn't
enough information for ptotobuf-net to work with, because the protobuf data
format doesn't include type metadata. It would have no way of recreating
That would depend entirely on what exact DLL you are using. Those methods
exist on all Full builds. I'm guessing you have referenced one of the
CoreOnly builds. The CoreOnly builds are intended for use with the
precompiler (
In all honestly I can't answer that off the top of my head, and I'm not at
a PC. I can investigate and get back to you.
Marc
On 19 Sep 2013 17:54, David Deutsch da...@reverenddave.com wrote:
I have the following member of a class:
public SerializableDictionaryint,
What is the property? A sub-object? A List? If the serializer doesn't think
it needs to call the setter: it won't. For example, the typical list
handling code could be paraphrased (not the actual implementation) as:
var list = obj.SomeList;
bool setValue = false;
if(list == null) {
Yes, OverwriteList should fix this. IgnoreListHandling does something very
different that doesn't apply here (see the intellisense comments for full
usage
Marc
On 19 Sep 2013 17:21, David Deutsch da...@reverenddave.com wrote:
So I *think* what is happening is that protobuf does a get of the
Yikes. Bug. Basically, the position field wasn't being reset when used
from the pool. This field is used for two main purposes:
- error reporting (telling the user at what offset it glitched)
- tracking sub-object ranges
I suspect that because it didn't reset, the field overflowed. This won't
Build r668 went out earlier to both nuget and google-code. I guess the 666
build was doomed to have an evil bug hiding away in there somewhere.
Marc
On 29 September 2013 10:06, Marc Gravell marc.grav...@gmail.com wrote:
Yikes. Bug. Basically, the position field wasn't being reset when used
This is specifically protobuf-net. I'd be happy to take a look, but is
there any context you can add about your specific model? As far as I know
there isn't a *general* reason for it to fail here. At the simplest : are
you able to make your model DLL available to me to use as a repro?
Note: due
I don't do much... no: *any* C++/CLI - but I guess the conflict here is
that the c++ generated classes are not going to be CLI-friendly. So you
need to either use a c++ library and c++ classes, or a managed library and
managed classes.
If your framework is unmanaged c++, then I *suspect* your
On 7 October 2013 10:45, Barzo dba...@gmail.com wrote:
In a meanwhile I have built the .cs generated file into a separate DLL
assembly and I added it (linked) to my C++/CLI project.
Indeed, compiling it as C# and referencing/linking was what I meant - i.e.
using the C# *from* C++/CLI, rather
Firstly: exactly what version is this? There was a bug in 663 relating to
threading (and which only exhibited after extended usage) that was fixed in
something like 668. If you are using something = 663 and 668 then please
update and retry.
Marc
(protobuf-net)
On 15 Oct 2013 16:22,
to the latest mono 3 master because of a
threading bug that was fixed 2 weeks ago, now this:)
Chris
On Tuesday, October 15, 2013 10:45:46 AM UTC-7, Marc Gravell wrote:
Firstly: exactly what version is this? There was a bug in 663 relating to
threading (and which only exhibited after extended usage
On 7 Nov 2013 20:32, Marc Gravell marc.grav...@gmail.com wrote:
What platform? But basically protobuf should be treated as a BLOB. Then
you have two choices:
- send it as a payload in an existing messaging stack
- write your own messaging layer on top of sockets - noting that because
If your intent is to get text from a to b, then there won't be a problem.
Protobuf uses utf-8, but that is an implementation detail that you should
never see. If your concern is that it may take more bytes in utf-8 than
utf-16 (for the codepoints in question), the you can always use a bytes
type
Can you be very specific with what you mean by connect with .NET Database
using Protocol Buffer? What **exactly** are you trying to do? And since
you are mentioning Http Request, Http Response and PHP - does
Database here really mean web-server ? Ultimately, the mechanism for
getting protobuf data
This is specific to protobuf-net; the inclusion of System.Xml is basically
linked to the PLAT_XMLSERIALIZER build symbol, which for the Full/Unity
configuration is currently:
DefineConstantsTRACE;FEAT_COMPILER PLAT_BINARYFORMATTER
PLAT_XMLSERIALIZER PLAT_NO_INTERLOCKED
101 - 200 of 335 matches
Mail list logo
