2013/12/8 Jens Munk Hansen <jens.munk.han...@gmail.com>

> Hi ChaiShushan
>
> I have looked into your c++ implementation and I really like the fact that
> it is portable. The POSIX components do not compile, but it was easy to
> fix, some names were wrong in rpc_posix_conn.cc.
>
Thanks for your feedback :)
I am a windows user, i have not do the test on posix system.
Can you submit some patch for POSIX compile issue?

>
> The software boss in our company likes standards and is trying to make a
> crew of software engineers with limited experience go from an almost
> monolithic structure into implementing their own services using DDS. We use
> Windows for a near real-time application (oh no).
>
For my protorpc, i just use golang protorpc server.
And my golang protorpc server run on windows right now,
but i don't care the OS(it is easy to switch to Linux with golang).
My rpc client run on the windows with C++ language.

>
> I am working on a project in my spare time, where I have used a simple C
> protocol allowing me set set remote parameters and execute remote
> functions. I wan't to use Kenton Vardas capnproto, but I would also like it
> to be cross-platform and cannot wait for this to be started.
>
I hear about the capnproto.
But i don't worry about the performance right now :)

>
> I really like your solution, except for the fact, that I would like not to
> change protoc (introduce return arguments for Services, remove the Closure
> concept, etc.) and be in sync with the main protocol buffers development.
> Another thing that I would to have is that all threads are outside the
> library and I can use a shared thread pool. I have sort of stolen some of
> your ideas and some ideas from Kenson Varda.
>
This solution is very like the Go standard RPC framwork.
And i implement the Go's protorpc first, and then implement the C++'s
version.
I am a newbie with C++ network pramgram.
So the C++'s protorpc server is just a toy for me.
And the C++'s protorpc client don't support asynchronous RPC call.
If need implement the asynchronous RPC call, we need use Closure for the
delayed replay.

>
> Some questions:
> 1) Are you still developing on this branch and do you think there is a
> possibility that you work will be part of the official protocol buffers?
>
There is no new feature in developing.
I use the C++ client now, and i will fix the bugs.
I don't think the official protocol buffers will accept my RPC solution(C++
and Go).

> 2) If you want to shutdown a server using a remote procedure you somehow
> need to exit the loop. I have implemented this in a command protocol, where
> a new callback is registered using the Closure concept. It is sort of hack,
> because one service is the able to shutdown others. Do you have any good
> ideas on how to implement this?
>
I don't think it is a really requirement for RPC.
We can shutdown the server in other way, eg: ssh.

> 3) What is your opinion about Captain Proto. Do you think it will become a
> standard for RPC?
>
I don't think there is a standard RPC!
As Gopher, i like Protobuf, because it is a standard package(Go team
created it).

>
> The reason for I would like to be in sync with protocol buffers is that we
> use for other stuff.
>
>
> On Sunday, July 21, 2013 4:20:51 PM UTC+2, ChaiShushan wrote:
>>
>> Hi Feng Xiao,
>>
>> I changed the url to https://code.google.com/p/protorpc/
>>
>> Now, go version can use `go get 
>> code.google.com/p/protorpc`<http://code.google.com/p/protorpc>install pkg.
>>
>> C++ version also need `hg clone 
>> https://code.google.com/p/protorpc.cxx/`<https://code.google.com/p/protorpc.cxx/>first.
>>
>> Please update the protorpc URL.
>> Thanks!
>>
>> 在 2013年5月9日星期四UTC+8上午1时56分44秒,Feng Xiao写道:
>>>
>>> Thanks, added to https://code.google.com/p/
>>> protobuf/wiki/ThirdPartyAddOns
>>>
>>> On Wed, May 8, 2013 at 6:33 AM, chai2010 <chais...@gmail.com> wrote:
>>>
>>>> Hi, I have create a protorpc project, impl RPC for Go/C++:
>>>>
>>>> https://bitbucket.org/chai2010/protorpc
>>>> https://code.google.com/p/protorpc/
>>>>
>>>> Some examples:
>>>> https://code.google.com/p/protorpc/source/browse/
>>>> protobuf/src/google/protobuf/rpc/example/
>>>>
>>>> Document(${root}/README.md):
>>>> https://bitbucket.org/chai2010/protorpc
>>>>
>>>> --
>>>> chaishushan
>>>> http://my.oschina.net/chai2010
>>>> http://chai2010.bitbucket.org/
>>>> http://golang-china.org
>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Protocol Buffers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to protobuf+u...@googlegroups.com.
>>>> To post to this group, send email to prot...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/protobuf?hl=en.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>>
>>>
>>>  --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at http://groups.google.com/group/protobuf.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
chaishushan
http://my.oschina.net/chai2010
https://bitbucket.org/chai2010

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to