Thanks both.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For
This whole conversation (proto / rpc) seems to have been very quiet
for a while. I'd be very keen to implement rpc for protobuf-net, so /
any/ kind of consensus would be good. I suppose I'd default to the
more Java compatible, but...
Marc
--~--~-~--~~~---~--~~
You
I'm writing the code-generation logic for protobuf-net, and I have got
it loading a compiled proto set (FileDescriptorSet). However, when
doing this I had a number of issues with invalid enum values (from
descriptor.proto, compiled via protoc).
In particular, OptimizeMode, CType and
I might have found the answer... if you try to provide a different
value, the parser will treat it like an unknown field (from the
language guide). So this means that enums are essentially unchecked:
invalid values are silently ignored?
Marc
--~--~-~--~~~---~--~~
More: actually, the problem wasn't in the file - it was in the
defaults... for example:
enum Label {
// 0 is reserved for errors
LABEL_OPTIONAL = 1;
LABEL_REQUIRED = 2;
LABEL_REPEATED = 3;
// TODO(sanjay): Should we add LABEL_MAP?
};
...
optional Label
Makes sense - it just seems a little odd that the optional enums don't
have a valid default...
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to
Ah! Right. That makes more sense. Could that perhaps be added to the
language guide Optional Fields And Default Values?
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this
I would have thought that there was a reflection-based json serializer
for java? A quick search yields JSON-RPC, but I'm not a java bod, so
I have no idea if this is any good.
Sticking to protocol buffers: not for java, but protobuf-net classes
(for .NET) are compatible with
For what it is worth, protobuf-net now has code generation support*,
and handles that file fine;
http://code.google.com/p/protobuf-net/source/browse/trunk/Examples/person.cs
Marc
[*=OK, it is a work in progress - I haven't added handlers for all the
combinations yet, but doesn't need much more
I'm currently working on the guts of a protorpc layer for protobuf-
net; so yes, any conversations here are very valued. Especially re
test rigs ;-p
I don't have any huge bias for/against either of the cited specs
(protorcp/protobuf-rpc). I just want something that works ;-p
Marc
Paul - I haven't looked at protobuf-rpc, but protorpc uses a .proto
message for the payload. One up-shot of that is that it should be (in
theory at least) fine to add extension properties to the message -
i.e. you could add a security object as an extended property. A given
server could check for
Actually, for the protobuf-net code-generator, I've gone down a
different route. I load the binary descriptor, and then serialize it
to xml. I then run this xml through an xslt transformation, and voila!
code. This has a couple of nice features:
* very easy (in theory) to add a whole new
Re point 1: no, you don't.
To illustrate, protobuf-net's protogen actually re-writes the
descriptor as xml. If you want, you can use this as is, just add a
new xslt and you're done:
protogen -i:foo.proto -o:bar.whatever -t:yourlanguage
Or if you want them as xml, this already exists:
(I've recently added protogen to the download section, here):
http://code.google.com/p/protobuf-net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to
I have no idea about the core C++ etc impementations - but if it
helps, protobuf-net builds for .NET CF 2.0 and .NET CF 3.5, if that is
any help. Note that there isn't an RPC stack for this yet, but I'm
working on it.
Marc
--~--~-~--~~~---~--~~
You received this
Sorry for the delay. Jon is correct: by *default* the Order is
required and is used as the tag number. However, if you want, there is
also a global switch that causes it to infer these by name (and the
Order if it is shared) instead. This was useful for a few users to
handle existing
I can only comment on protobuf-net. It is now pretty stable and
robust, and covers all common .NET variants (I haven't tried compiling
it on micro-framework, but that is about it...). I could probably do
to iron out a few kinks in the code-generator (protogen), but the core
engine is pretty
If you think about it, what you describe is not much different to if
I write the binary using C++, can I read it with java / C# /
ActionScript / etc - since they all have different code describing
the same binary wire-format.
The answer is: yes, (assuming there are no significant bugs between
After a few abortive starts, I'm keen to keep pushing on the C#/RPC
front... if the wire format / methodology is documented (and
sensible ;-p), I'd happily have a stab at a C# client/server - the
intent being to be able to talk cross-architecture.
Marc (protobuf-net)
I have already replied directly via e-mail, but for the list's
benefit: protobuf-net now has support for this in r231; this is
*mainly* tweaks to the code generation to emit the extra members, but
for convenience some changes were made to the core too.
Marc Gravell
I'm pretty happy with ongoing general maintenance, but with Jon
working for Google, and it being a closer port of the existing
implementations... I'd realistically expect things may be a little
stacked in favour of that one.
Even if that comes to pass, I'll still maintain protobuf-net anyway,
that anyone has used for such? Or just application/
octet-stream?
Marc Gravell
--~--~-~--~~~---~--~~
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
inconvenience.
Marc Gravell
--~--~-~--~~~---~--~~
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
I have logged this on the protobuf-net site:
http://code.google.com/p/protobuf-net/issues/detail?id=50
Marc Gravell
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send
is not terminated; messages will bleed
into each-other unless you separate messages. You can do this using
SerializeWithLengthPrefix and DeserializeWithLengthPrefix, which
include the length of the message and only read that much data from
the stream.
Marc Gravell
Maybe I'm missing the point - but that would change the data? The
binary file doesn't include whitespace (etc) except for in strings
that are user data.
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol
Your point is valid, in that I need to update the documentation to
make things a bit clearer. So many tasks, so few hours...
If you have any other problems, please don't hesitate to ask,
Marc Gravell
--~--~-~--~~~---~--~~
You received this message because you
Quick question - which build are you using? (at client and server)?
Based on the field names, the code-generation dates back to November;
if the dlls are aged similarly, it is possible that this is an old
bug. If possible, can you retry with the current build?
I'm just trying the code you
You can't use unicode to transport arbitrary binary data - it won't be
a valid unicode string. If you have to use strings, then base-64 is
the safest option:
private string Serialize(OrderProto proto)
{
using (MemoryStream stream = new MemoryStream())
{
(re last post)
As with unicode, you can't use ASCII to handle raw binary; either use
base-64 (previous post), or send binary.
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to
I've just been looking more - and ParseFromString should do the job.
I /suspect/ the problem is the definition a string... you aren't
going to be able to treat raw binary in .NET as a String; you are
going to have to treat it as a Stream or a byte[], or you can encode
it to base-64 (as above) to
OK; I'm investigating now... As an aside - if you are going to read
the entire file, you might as well use File.ReadAllBytes(path) - it'll
be a lot easier.
I'll see what I can find out...
Marc Gravell
--~--~-~--~~~---~--~~
You received this message because you
In many ways this is an implementation detail, though. protobuf-net
takes the other (mutable classes) approach - and indeed one
consequence is that it needs to be careful about loops when
serializing. That needn't be too invasive, though: I simply track the
depth, and don't even bother tracking
What implementation are you using? Given that most of the
implementations use code-generation (rather than reflection), I'm
wondering if this is protobuf-net?
(since that supports inheritance by representing it as nested
messages).
Marc
--~--~-~--~~~---~--~~
You
refactor), but it could *potentially* work -
*if* there is a good scenario for it...
Marc Gravell
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf
).
Thanks hugely to Michael Thaler and Rüdiger Klaehn, who contributed
this.
I'm also now wondering what other .NET languages I can (usefully)
support - as each is typically just a case of adding a single template
file.
Marc Gravell
--~--~-~--~~~---~--~~
You received
Related to the new packed encoding... this ties in neatly with a bug
report I'm looking at (protobuf-net) re repeated bytes. I'm given to
understand that this will be treated *broadly* as jagged data (albeit
with wrappers etc).
Are there any plans to extend this to the other packed types? My
I'm sorry - I didn't do a good job with the question...
I meant with things like integer, float, etc...
With the packed encoding, it *seems* like it would be possible to send
jagged array-like data fairly efficiently.
I wasn't referring to string/message.
Marc
API to the main Google api (which
may be a re-statement of the first point, come to think of it...)
http://code.google.com/p/protobuf-net/
Marc Gravell
(protobuf-net)
On Jun 6, 1:29 pm, ualtinok ufukalti...@gmail.com wrote:
Hi Jon,
Is there any news on Silverlight ? We are approaching to SL3
I'm using protoc as the raw .proto parser for protobuf-net (I then
process the compiled binary for code-generation); at the moment, it is
very sensitive about line endings - if it isn't LF, it won't work.
This creates a bit of a nag for Windows users, as you have to go out
of your way to get the
OK... is there any way it /could/ silently ignore the BOM? ;-p
I can try to advise the caller to use files without BOMs, but protoc
reads UTF8 anyway it seems reasonable to accept a BOM?
Marc
--~--~-~--~~~---~--~~
You received this message because you are
; then the entire list
of implementations would be visible on a single page (just a thought).
Thanks,
Marc Gravell
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email
I'm happy to say that protobuf-net now features VS2008 integration.
Please see the following page for more information:
http://marcgravell.blogspot.com/2009/07/protobuf-net-now-with-added-orcas.html
Marc Gravell
(protobuf-net)
--~--~-~--~~~---~--~~
You received
Nice work - makes my port look somewhat hard work :)
The source is fully available, so feel free to look at how it hangs
together; you'll need to get your own VSIP key, of course.
If I can ever call the native protoc library using P/Invoke
If you figure that one out, let me know - I'm
, so you can
describe a model against types separately (including adding protobuf-
net support for types outside of your control).
I haven't been able to progress that branch lately (available time
etc) - but I very much plan on completing that work...
Marc Gravell
Not really, except for convenience; and actually, most of the code-gen
in this case is actually done in xslt, not directly in .NET (protogen
is very shallow in terms of what it does; most of the code is parsing
command-line inputs... it only looks fat because it contains an
embedded copy of
(oops, ignore the double-click!)
From ProtoContract, I'm taking this to be a protobuf-net question.
No, it doesn't currently offer a way to serialize structs; the main
reason for this being that structs should pretty-much always be
immutable, which makes a reflection-based API (such as
Part of the problem here is that I can't think of a clean way to do it
that doesn't go mad with boxing, or losing struct changes. I'm
guessing that for xna you have mutable structs, so immutability isn't
necessarily an issue, but then I need lots of ref instead... Fun...
Also; note that the CF
The problem is the root certificate (CA Cert Signing Authority) - it
certainly isn't in my trusted set of root certificates...
On Aug 19, 3:50 am, opticron nyphb...@gmail.com wrote:
It is a CACert certificate that is valid until May of 2010.
On Aug 18, 7:46 pm, Kenton Varda ken...@google.com
Just to offer my thanks as well, since I was offline at the time and
unable to help.
Regards,
Marc Gravell (protobuf-net)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post
(d'oh; replied to wrong address...)
I'm fairly sure that 3 is correct; if it was 3, then 3 bits of
field_number would be lost, and the next 3 would overlap with wire_type.
I did notice an error in the language document though - a missing semicolon
relating to imports, IIRC...
Marc
2009/8/28
to
implement and maintain 2 protobufs for each object in the client, just
for display purposes.
Thanks
On Sep 29, 10:58 am, Marc Gravell marc.grav...@gmail.com wrote:
In protobuf-net? No. You could deserialize into the expected type and
use reflection, though. It is perhaps something I
(damn, I forgot to reply-all again!)
It is also entirely possible that the two things are unrelated, in which
case: sorry for any confusion.
But I do know that it is painfully easy to get BOM-heavy files if you use
Visual Studio, and that protoc doesn't like it; I can't remember which error
File - Advanced Save Options... - Encoding: Unicode (UTF-8 without
signature) - Codepage 65001
Marc
2009/11/13 Kenton Varda ken...@google.com
There should be a setting somewhere in visual studio to make it not use
BOMs.
On Thu, Nov 12, 2009 at 6:10 PM, Tommi Laukkanen
If you treat it as a string (UTF8), you are likely to get garbage. If you
treat it as a byte[], then you just get a BLOB - you don't lose anything,
but you might not be showing some more detail that you could show.
You could, however, check for likely-sub-message-ness - i.e. after getting
the
That is actually pretty similar to a scheme I had in mind to (opt-in only)
get protobuf-net working at graph serialization. I don't think it would be
easy to fit into the existing .proto or codegen, but protobuf-net doesn't
actually demand these.
Before I go on - the first thing I'll say is that
For info only, protobuf-net currently uses:
internal const string HTTP_RPC_VERSION_HEADER = pb-net-rpc;
internal const string HTTP_RPC_MIME_TYPE = application/x-protobuf
;
(version for my own internal purposes, in case I need to change the body
layout)
Re the sockets point also
for subclasses on the fly would be messy, and I can't
include the type metadata without breaking completely from the standard
protocol buffers wire format.
Marc Gravell
(protobuf-net)
2009/12/10 Bartosz Pierzchlewicz bar...@extranet.one.pl
Hello,
I have two classes:
[DataContract
Re the whole what should an endpoint url look like thing - I had a similar
discussion with a user re protobuf-net; in the end it was quicker to just
*default* to the former (since it doesn't need any extra specification), but
*support* both - so the code detects key strings in the supplied url and
I'll definitely try that later ;-p
2009/12/11 Pavel Shramov shra...@mexmat.net
On Fri, Dec 11, 2009 at 11:01:20AM +0300, Pavel Shramov wrote:
I've set one at http://psha.org.ru/pbuftest/?{service}.{action}
Forgot to mention that it is standart Test service with Echo call
and Math service
Hmmm... that should work fine; there *was* a related bug in an early build,
but...
Can I check which version and framework you are using? I've checked on r275,
and it works fine as is, for both empty lists and some arbitrary data I
made up.
Sorry for the delay, btw - seasonal break, etc...
Marc
OK; I'll re-check with the Net20 variant...
2009/12/19 jeevankodali jeevankod...@gmail.com
Thanks for the reply. I used r278 and Net20 folder in that zip file.
On Dec 18, 2:36 pm, Marc Gravell marc.grav...@gmail.com wrote:
Hmmm... that should work fine; there *was* a related bug in an early
can add the code that I am using, do you need the file as
well (and how can I send the file)?
Thanks
On Dec 19, 5:09 pm, Marc Gravell marc.grav...@gmail.com wrote:
Rechecked with Net20 from the r278 build, and it worked fine. Sorry to be
a
pain, but do you have a complete example
That is pretty vague, but protocol buffers is a binary format, so
whatever BLOB datatype that your store supports should be fine. Other
than that you should be OK.
Can you give more information as to your setup?
Marc Gravell
--
You received this message because you are subscribed to the Google
).
Thanks,
Marc Gravell
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit
(I believe the term I failed to use here is over-long forms)
On Mar 10, 3:48 pm, Marc Gravell marc.grav...@gmail.com wrote:
The variable-length encoding allows multiple representations of the
same value - for example, 1 could be written as:
0001
or it could be (I believe):
1000
Cheers all; some useful input.
Before I get too excited, I'll run some quick tests and simply compare
writing as group vs string with my current code (since I can flip
between them trivially and groups don't involve any shuffling).
Marc
On Mar 10, 10:26 pm, Evan Jones ev...@mit.edu wrote:
Hmm - the data field should be pretty trivial - in terms of the wire-format
it is just a field-header, a length-prefix, and then the raw data.
How big is the message when serialized? (or: how big is a short message that
reproduces this problem?) Could you possibly both the BLOB, either in hex or
I'm really glad you found the cause of this; you had me worried I'd done
something horrible with the .NET encoding ;-p
Probably one for Kenton, but I wonder if it might be prudent to include
VS2008 (and presumably VS2010) project files for the core project?
Marc
On 14 March 2010 07:25, Roey
Hi Fred - that is unfortunately pretty vague - can you clarify exactly what
happens? The most common mistake when using a MemoryStream is to start
reading from it without resetting the Position to 0 (essentially, rewinding
it).
The other common mistake is to try overwriting it (from the
With protobuf-net? Sure; use Serializer.NonGeneric.Serialize(ms, obj);
Marc
On 19 March 2010 22:06, Rich76 vspin...@aol.com wrote:
Is there any way to do this?
public static byte[] Serialize(Object obj)
{
using (MemoryStream ms = new MemoryStream())
{
Hi; that is protobuf-net, which has a very different API to some of the core
google libs. It supports use frmo .proto, but is also intended to work
reasonably nicely with common / existing .NET types (that /aren't/ generated
from .proto).
To that end - it indeed supports generics at runtime; this
In the case you don't have the definition (perhaps a network inspector), you
could always *try* to parse it as UTF8 - if it passes as UTF8 the chances
are fairly good that it truly is a UTF8 string - and the confidence should
go up as the string gets longer (since the chance of a random .proto
d'oh! Engage brain, then talk! Yes, you're entirely right; testing it as a
sub-message and trying UTF8 as a fallback makes a lot more sense.
Marc
On 16 April 2010 03:23, Kenton Varda ken...@google.com wrote:
On Thu, Apr 15, 2010 at 2:55 PM, Marc Gravell marc.grav...@gmail.comwrote
And actually, an equivalent *already* exists - simply define your message
using groups rather than nested sub-messages. The disadvantage of this is
the same as with your proposal: if this data is an unexpected member you
need to inspect each field (although maybe not parse it entirely) to skip
, Marc Gravell marc.grav...@gmail.com wrote:
and you process the last 2 bytes separately, of course; it is field 101 of
type string (or sub-message or bytes), length 14, with the actual data
missing.
Marc
On 19 April 2010 15:53, Marc Gravell marc.grav...@gmail.com wrote:
I know it wasn't
That is pretty-much how protobuf-net handles it (although the trunk does
have a strict mode that enforces exact matches on wire-types). You'd still
have the issue of older code expecting a length-prefix and getting a
start-group, so even it is allowed either during deserialization, you'd want
it
In the case of repeated strings etc (excluding the enum case), I've been
toying whether something is possible by associating certain objects / values
with unique identifiers on the wire. Potentially this would also allow
graph (rather than tree) serialization.
This is obviously well into the hazy
You mention attributes; what implementation are you using? protobuf-net (one
of the .NET implementations) uses .NET attributes as one mechanism for
describing fields; is this what you mean? If it is, then I have a
soon-to-be-released v2 of protobuf-net which indeed allows independent
metadata (as
... pardon me... it will
be my interpretation).
I have a base test for IDocumentSerializerTDocument and I have tried
some others serializer and, so far, I'm stuck with .NET binary
formatter.
Looking forward for protobuf-net V2.
Thanks Marc.
On 4 mayo, 17:22, Marc Gravell marc.grav...@gmail.com
a database. Which protocol buffers isn't.
Marc Gravell
On 14 May 2010 11:31, Kevin Apte- SOA and Cloud Computing Architect
technicalarchitect2...@gmail.com wrote:
I saw that ProtoBuf has been benchmarked using the Northwind data
set- a data set of size 130K, with 3000 objects including
It omits:
[Serializable] against types (for use if you are using protobuf-net
**within** BinaryFormatter, perhaps for remoting purposes)
[Browsable(false)] against the {name}Specified properties that help guide
XmlSerializer
[ProtoBehavior] against operation-contracts (since Silverlight etc
(else: we've mucked it up).
The various C# (/.NET) implementations are listed here:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
Marc Gravell
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email
Kenton is of course quite correct. There is no *native* distinction between
a null list and an empty list in the raw protobuf data stream. There *are*
some ways of working around that, to distinguish between the two, but not
when using the code-generation from .proto.
Marc
On 22 June 2010 18:59,
in the message that determines if the list is empty or
not. What do you think?
On Jun 22, 1:21 pm, Marc Gravell marc.grav...@gmail.com wrote:
Kenton is of course quite correct. There is no *native* distinction
between
a null list and an empty list in the raw protobuf data stream. There
*are*
some
From the encoding spec, it is required (or at least: recommended) to handle
out-of-order fields. I guess *in part* this helps with message
concatenation. I also know of at least one case where I knowingly emit
fields out of order (in my implementation; not related to the core Google
Since an outermost protobuf message does not include either a delimiter or a
length, it is (for this scenario) necessary either to include your *own*
message boundary mechanism, or for single messages just close the stream.
The most common approach seems to be simply to include the length as a
Now add a field for A (which is legitimate) and it all falls apart.
Possibly a *viable* representation might be:
message C {
optional A field_a = 1;
optional B field_b = 2;
optional int32 field_c = 3;
}
and that is something that *can* be understood today, by all
implementations,
From the message, that *sounds* like protobuf-net...
There is no built-in handling of this, but it is possibly something that
could be added, especially in v2 which has a much more flexible model. For
example, you *could* argue that there is an implicit schema that uses a
repeated element per
You could simply sign the chunk of data manually; but no - protobuf does not
include any provision for this. I *imagine* because the requirements will be
so different system-to-system.
On 21 July 2010 11:32, Prakash Rao prakashrao1...@gmail.com wrote:
curity layer to protocol buffer if I'm
If you can show me a format which offers faster serialisation or
deserialisation
than JSON in a .NET application, I'd be impressed! :)
In .NET? Sure: vs which json engine? I'm pretty certain that protobuf-net
(especially v2, but probably v1) can thrash it.
This is v1, which is quite a bit
And of course, if you *are* happy using WCF and .NET, with all the
simplicity that provides, you can *still* use protobuf, since protobuf-net
includes a WCF hook that (if you desire) swaps-out the serializer used by
WCF. So your *existing* .NET code (bereft of any .proto definition) can
enjoy
Ooh - interesting. I'll have to take a good look at that shortly. I'm
thinking mainly C#-to-C# (due to my particular interests), and I'm also
wondering what v2 might do to help you ;p
Marc
On 12 August 2010 00:17, Niall niallsspamcollec...@gmail.com wrote:
Could I get a link to it added on the
If you mean . Net data sets, I blogged about this earlier this week:
marcgravell.blogspot.com
Note I only experimented with a single DataTable, but that is most of the
hurdle. The code using protobuf-net v2 is **experimental** and incomplete, but
committed. If if is something you'd be
. If it isn't yet able to serialize a full DataSet, I can
certainly try to finish the coding for that.
Thanks!
- Andrew
On Oct 15, 2:14 pm, Marc Gravell marc.grav...@gmail.com wrote:
If you mean . Net data sets, I blogged about this earlier this week:
marcgravell.blogspot.com
Note I
In terms of output? GZIP / DEFLATE / etc implementations should be
interoperable between platforms, yes. However IIRC the compressed stream is
not guaranteed to be byte-identical between specific implementations (but
the *decompressed* stream should be byte-identical)
Marc
On 19 October 2010
Speaking specifically to protobuf-net:
1: there is no formal xml spec, and you should generally **only** need this
for writing a template file, but passing -t:xml to protogen should do what
you ask
2: do you mean without using the plugin? There is a command-line tool
protogen included in the zip
.
What about the other direction - converting from XML to .proto file?
How can I achieve that?
As for the 2nd question below I meant how can I generate C# classes
without using the protogen.exe (in code).
Thanks,
Ofir
On Nov 3, 8:53 am, Marc Gravell marc.grav...@gmail.com wrote
As far as the binary encoding is concerned, it won't care. Obviously any
code involved would need to be changed, and it *might* impact the text-based
encoding (I don't know for sure; I simply don't use this encoding).
Marc
On 18 November 2010 16:56, Cameron cameron.develo...@gmail.com wrote:
Note that the protobuf-net *inside WCF* is going to be largely .NET/WCF
specific.
If you want to talk cross-platform, vanilla HTTP would be preferable, or
alternatively just transfer a `byte[]` or `Stream` in your regular
web-service tools of choice.
(note also: MTOM may be helpful if your
1 - 100 of 335 matches
Mail list logo
