On 12/09/2009 09:00 PM, Kenton Varda wrote:
Actually I don't think we need DescriptorPool in Java. DescriptorPool
was primarily written for the purpose of memory management, but Java
handles that for us. If all you need is the mapping aspect, just build
a MapString, ServiceDescriptor
Is this for the RPC system? I think you're making this a lot harder than it
needs to be.
On the server side, when someone wants to export a service, they will
construct a service implementation and pass it to your system. The
com.google.protobuf.Service interface has methods getDescriptor(),
2009/12/10 Romain François francoisrom...@free.fr
On 12/09/2009 09:12 PM, Kenton Varda wrote:
Coincidentally, last weekend I started working on an open source
protobuf-based RPC system. Currently I am defining a socket-level
protocol, but I also intend to support an HTTP-level protocol with
On 12/10/2009 10:13 AM, Kenton Varda wrote:
Is this for the RPC system?
yes
I think you're making this a lot harder
than it needs to be.
ah.
On the server side, when someone wants to export a service, they will
construct a service implementation and pass it to your system. The
2009/12/10 Romain François francoisrom...@free.fr
Cool. Do you have your layout documented somewhere in your project.
Embed service full name and method name in the http request as we do allows
the request to be self-contained. What kenton suggests needs the client to
know of the mapping
On 12/10/2009 11:13 AM, Kenton Varda wrote:
2009/12/10 Romain François francoisrom...@free.fr
mailto:francoisrom...@free.fr
Cool. Do you have your layout documented somewhere in your project.
Embed service full name and method name in the http request as we do
allows the request
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
On 12/10/2009 05:30 PM, Marc Gravell wrote:
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
Hello,
I have two classes:
[DataContract]
public class TestClass: BaseTestClass
{
[DataMember(Order = 1)]
public string Str { get; set; }
}
[DataContract]
[ProtoInclude(1,typeof(TestClass))]
public class
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
One compression algo that I thought would be particularly useful with PB's
would be LZO. It lines up nicely with PB's goals of being fast and compact.
Have you thought about allowing an integrated LZO stream?
--Chris
On Wed, Dec 9, 2009 at 12:21 PM, Kenton Varda ken...@google.com wrote:
Thanks
Re the sockets point also raised; there's a lot of difference between raw
sockets and http; it would be good to get some kind of official http
transport working - people can always add raw later...?
This is exactly the point I was trying to raise: if you bind Protocol
Buffer RPC to a transport
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
Hi Bartosz;
At the moment, it only supports the reflection/attribute based approach
(directly comparably to the [KnownType] attribute used in vanilla WCF /
DataContractSerializer). I have some plans and prototype code to rectify
this (runtime models), but it is lots of work, and it isn't anything
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 then
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
On Thu, Dec 10, 2009 at 8:13 AM, Mikhail Opletayev opleta...@gmail.comwrote:
It's great news that you working on a standard way to communicate
between Protocol Buffers implementations!
You don't need to send the service name at all. The server should
already
know what kind of service it
The errors suggest to me that somewhere you have #defined Arc as a macro.
Is this possible?
On Thu, Dec 10, 2009 at 9:21 AM, bayWeiss bzwr...@yahoo.com wrote:
I cant post the whole generated .h file, but below is a snippet where
for some reason the compiler cant identify the Arc class. The
Interesting. Essentially a discovery service for protobuf RPC.
I am not quite sure what you mean by pointers to other services. Is
it going to reference them by name or a more complex structure
containing full endpoint information?
Also, is it going to be an extension to pbcap or something
BTW, I haven't defined how pbcap/Captain Proto will work over HTTP yet. So,
I'm only talking about the raw-socket protocol.
On Thu, Dec 10, 2009 at 2:42 PM, Kenton Varda ken...@google.com wrote:
On Thu, Dec 10, 2009 at 2:37 PM, Mikhail Opletayev opleta...@gmail.comwrote:
Interesting.
Interesting. Essentially a discovery service for protobuf RPC.
I am not quite sure what you mean by pointers to other services. Is
it going to reference them by name or a more complex structure
containing full endpoint information?
Also, is it going to be an extension to pbcap or something
Sorry for the double post :/
I understand that you are talking about raw raw-sockets. From my
perspective, it's a good thing as it doesn't tie the RPC protocol to
any specific transport protocol.
Currently it references them by an ID number that is tied to the particular
connection. So, each
Ok, some more info.. thanks to your help
So I renamed Arc to ArcShape in the protofile, for example, and it all
works fine.
Funny thing is, if I rename Square to Polyline, I get the same
errors.
If I rename Polyline to PolyLine.. all is ok.
Using Ellipse throws errors also...
So, I guess I
Maybe ask the compiler for the pre-processed output (sorry, I don't know the
VS2008 flag), and search through that for the first appearance of those
identifiers. That'll tell you what header they come from.
Adding a package should fix this kind of problem by putting all of the
messages in a c++
On Dec 10, 2009, at 18:33 , Kenton Varda wrote:
client: Open service Foo.
client: When request 1 is complete, call method Bar() on the
result.
I'm curious: Why have the Open request at all? Why not just cal
method Foo.Bar()? Are you planning on supporting some concept of
sessions?
On Thu, Dec 10, 2009 at 4:07 PM, Evan Jones ev...@mit.edu wrote:
On Dec 10, 2009, at 18:33 , Kenton Varda wrote:
client: Open service Foo.
client: When request 1 is complete, call method Bar() on the result.
I'm curious: Why have the Open request at all? Why not just cal method
29 matches
Mail list logo
