[
https://issues.apache.org/jira/browse/MESOS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Vetoshkin updated MESOS-930:
-----------------------------------
Description:
This ticket is the result of the discussion started in mailing list
(http://www.mail-archive.com/[email protected]/msg05477.html).
It would be great if Mesos provided protocol for slave<->executor communication
additionally to currently provided c++ based language bindings.
ocumenting
wire protocol could open ways to implement Executors in pure python or
golang or any other language. It could provide some benefits:
* in Python one could use gevent which is pretty popular
* golang has it's own eventloop builtin
* pure language binding could save a lot of trouble bridging with
unfriendly C++
* building and using pure language client could be performed using native
tools like `pip install` or `go get` without need to establish c++ dev
environment.
Before moving any further we need to decide, if this is actually a good thing
to do. According to discussion in mail list - looks like it's worth doing.
So next logical thing is to decide:
* should protocol be something utterly new
* should we document current protocol used by libprocess
* should libprocess protocol be brushed a little before documenting it for
external implementation
While waiting for discussion I'd like to start documenting current protocol.
Where can one do it in a way suitable for comments? RB?
was:
This ticket is the result of the discussion started in
((http://www.mail-archive.com/[email protected]/msg05477.html mailing list)).
It would be great if Mesos provided protocol for slave<->executor communication
additionally to currently provided c++ based language bindings.
ocumenting
wire protocol could open ways to implement Executors in pure python or
golang or any other language. It could provide some benefits:
* in Python one could use gevent which is pretty popular
* golang has it's own eventloop builtin
* pure language binding could save a lot of trouble bridging with
unfriendly C++
* building and using pure language client could be performed using native
tools like `pip install` or `go get` without need to establish c++ dev
environment.
Before moving any further we need to decide, if this is actually a good thing
to do. According to discussion in mail list - looks like it's worth doing.
So next logical thing is to decide:
* should protocol be something utterly new
* should we document current protocol used by libprocess
* should libprocess protocol be brushed a little before documenting it for
external implementation
While waiting for discussion I'd like to start documenting current protocol.
Where can one do it in a way suitable for comments? RB?
> Provide slave<->executor protocol
> ---------------------------------
>
> Key: MESOS-930
> URL: https://issues.apache.org/jira/browse/MESOS-930
> Project: Mesos
> Issue Type: Improvement
> Components: general
> Reporter: Nikita Vetoshkin
> Priority: Minor
>
> This ticket is the result of the discussion started in mailing list
> (http://www.mail-archive.com/[email protected]/msg05477.html).
> It would be great if Mesos provided protocol for slave<->executor
> communication additionally to currently provided c++ based language bindings.
> ocumenting
> wire protocol could open ways to implement Executors in pure python or
> golang or any other language. It could provide some benefits:
> * in Python one could use gevent which is pretty popular
> * golang has it's own eventloop builtin
> * pure language binding could save a lot of trouble bridging with
> unfriendly C++
> * building and using pure language client could be performed using native
> tools like `pip install` or `go get` without need to establish c++ dev
> environment.
> Before moving any further we need to decide, if this is actually a good thing
> to do. According to discussion in mail list - looks like it's worth doing.
> So next logical thing is to decide:
> * should protocol be something utterly new
> * should we document current protocol used by libprocess
> * should libprocess protocol be brushed a little before documenting it for
> external implementation
> While waiting for discussion I'd like to start documenting current protocol.
> Where can one do it in a way suitable for comments? RB?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
