On Thu, Jun 13, 2013 at 08:43:19AM -0700, Giri Guntipalli wrote:
Hi michael, does it handle extensions as well. i mean extensions of pb to
json and vice versa.
Now - yes. However should be tested in real environment.
Pavel
--
You received this message
On Sun, Jun 03, 2012 at 11:02:13PM -0700, Shail wrote:
Thanks. I see that you have provided link which talks about XQuery
like support for Python.
I am using C# C++ version for protocol buffers.Is currently any plan
of XPath/SQL query like support for C++/C#?
You may try to contact Greg
On Wed, Nov 24, 2010 at 02:54:58AM -0800, mvbaffa wrote:
Do you have any reference of a real example sending and receiving
information using, including HTTP protocol.
Search mailing list for 'http'. It was discussed numerious times already.
For example I'm using protobuf over http (with
On Fri, Sep 17, 2010 at 01:50:54PM -0700, Greg Adair wrote:
Just curious, is your code licensed under the New BSD license like
Protocol Buffers is?
My employer's lawyers are very particular about licensing when it
comes to what I can use or contribute to for use in a product.
Since most of my
On Thu, Sep 16, 2010 at 05:37:03PM -0700, Greg Adair wrote:
Hello Pavel and Scott,
Did this XPath-like functionality for protocol buffers end up going
anywhere?
I would definitely be interested in using and extending what you guys
described. I need what is described on the message board,
On Fri, Mar 12, 2010 at 04:17:37PM -0500, Andrew Kimpton wrote:
I've started a small project at
https://code.google.com/p/protobuf-jerpc/which contains an
implementation of a protoc plugin that outputs essentially
the same classes etc that the current generic services mechanism outputs
(but
On Fri, Dec 18, 2009 at 07:01:36AM -0800, Scott Stafford wrote:
We don't have a formal spec of it or anything, but from what I can
tell we evolved the same syntax as the internal Google effort. No
frills, just a sequence of N field names separated by dots (.). I'll
try to write out the rules
On Fri, Dec 04, 2009 at 02:17:33PM -0800, Scott Stafford wrote:
Hi -
We built a simplified XPath-like syntax (and implementation for C++)
to control the Reflection interface via strings. For instance,
... skip ...
PBPath::GetInt32( myMessage, field2[id=50].field3[1] );
would search
On Thu, Dec 10, 2009 at 09:48:29PM +, Marc Gravell wrote:
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
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 [1].
Pavel
--
[1] http://grid.pp.ru/cgit/psha/pbufrpc/tree
On Wed, Dec 09, 2009 at 12:10:33PM +0100, Romain François wrote:
Hello,
Following Kenton's advice, I'm starting to look at implementing protobuf
rpc over http. I have started to work on a basic java server (based on
the com.sun.net.httpserver class). I will post this at some point when I
On Thu, Dec 10, 2009 at 05:06:09PM +0100, Romain François wrote:
I'm using method name encoded in query part of URL like
/base/url?Service.Method
That seems odd. Why not /base/url?service=Servicemethod=Method instead ?
For simplicity (from my point of view). Query string is here only to
On Thu, Dec 10, 2009 at 05:44:48PM +0100, Romain François wrote:
-
POST /{root}/{service full name}/{method name} HTTP/1.0
Content-Length: {length of the serialized message}
Content-Type: application/x-protobuf
{raw bytes of the serialized
On Thu, Dec 10, 2009 at 06:23:14PM +0100, Romain François wrote:
What about then if you want to control the kind of output that is
returned back (pb or json). I would then add encoding=pb or
encoding=json. How do you do this ?
Everything is invented before us [1] :)
To be fair in my
Disclaimer: I'd be happy if once one of raw async RPC would be
'standart' but now maybe HTTP one will be. They just suppliment each other.
On Thu, Dec 10, 2009 at 09:41:15AM -0800, Mikhail Opletayev wrote:
Re the sockets point also raised; there's a lot of difference between raw
sockets and
On Thu, Dec 10, 2009 at 07:56:49PM +0100, Romain François wrote:
On 12/10/2009 06:31 PM, Pavel Shramov wrote:
On Thu, Dec 10, 2009 at 06:23:14PM +0100, Romain François wrote:
What about then if you want to control the kind of output that is
returned back (pb or json). I would
On Sun, Feb 08, 2009 at 10:13:12PM -0800, Shardul Deo wrote:
Let me know if you have any questions (or if there is something better
that I can use instead),
Why You have not considered taking one of existing wire format
specifications [1, 2, 3]? Having field of service description is nice
but
On Sun, Feb 15, 2009 at 12:35:17PM -0800, Shardul Deo wrote:
Pavel,
I didn't want to have my code depend on anything else other than the core
protobuf library which is why I wrote my own wire spec.
I could remove service from my request format or add it to [1], but that
would still not make
On Wed, Jan 07, 2009 at 06:23:31PM -0800, Alan Kligman wrote:
I poked around a bit and the code above isn't correct (for a couple of
reasons). But the question remains: should stubs be generated that
return the response down the callstack instead of passing it through a
callback function?
Sun Nov 16 11:29:13 MSK 2008 Pavel Shramov [EMAIL PROTECTED]
* Drop unused build-dependencies from protocol-buffers.cabal
haskell-src is only used in hprotoc
syb-with-class is not used at all (at a first glance)
This fix build failures on debian/lenny with ghc 6.8.2
Sun Nov 16 11
On Fri, Nov 07, 2008 at 10:04:27AM -0800, Kenton Varda wrote:
I don't know Python very well. Petar, can you verify this is correct? (I
tried it and the tests still pass.)
Problem is raising both in tests and in real applications.
Both svn trunk and 2.0.2 version fail (will be strange if one
On Sun, Oct 05, 2008 at 11:41:53AM +0200, Iustin Pop wrote:
i386: result is type 'long', expected is type 'long'
amd64: result is type 'int', expected is type 'long'
I don't understand exactly what's going on, but I think the problem is
that an i386 system cannot represent that constant as
22 matches
Mail list logo
