[jira] [Comment Edited] (MESOS-1127) Implement the protobufs for the scheduler API

["Vinod Kone (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14320683#comment-14320683 ] 

Vinod Kone edited comment on MESOS-1127 at 2/13/15 8:11 PM:
------------------------------------------------------------

Yea. I was suggesting to keep the REGISTERED/REREGISTERED *types* but get rid of *Reregistered* protobuf (and keep the Registered protobuf).

A registered response for example would like this.

{code}
HTTP/1.1 200 OK

Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive

{
  “type” : “REGISTERED”,
   
  “registered” : {
      “framework_id” : { “value” : “12220-3440-12532-2345”} 
  } 
}
{code}

A re-registered response:
{code}
HTTP/1.1 200 OK

Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive

{
  “type” : “REREGISTERED”
}
{code}

Anyway, hopefully this all will make more sense once we open up the design doc. Stay tuned.


was (Author: vinodkone):
Yea. I was suggesting to keep the REGISTERED/REREGISTERED *types* but get rid of Registered and Reregistered protobufs.

A registered response for example would like this.

{code}
HTTP/1.1 200 OK

Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive

{
  “type” : “REGISTERED”,
   
  “registered” : {
      “framework_id” : { “value” : “12220-3440-12532-2345”} 
  } 
}
{code}

A re-registered response:
{code}
HTTP/1.1 200 OK

Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive

{
  “type” : “REREGISTERED”
}
{code}

Anyway, this all hopefully make more sense once we open up the design doc. Stay tuned.

> Implement the protobufs for the scheduler API
> ---------------------------------------------
>
>                 Key: MESOS-1127
>                 URL: https://issues.apache.org/jira/browse/MESOS-1127
>             Project: Mesos
>          Issue Type: Task
>          Components: framework
>            Reporter: Benjamin Hindman
>            Assignee: Benjamin Hindman
>              Labels: twitter
>
> The default scheduler/executor interface and implementation in Mesos have a few drawbacks:
> (1) The interface is fairly high-level which makes it hard to do certain things, for example, handle events (callbacks) in batch. This can have a big impact on the performance of schedulers (for example, writing task updates that need to be persisted).
> (2) The implementation requires writing a lot of boilerplate JNI and native Python wrappers when adding additional API components.
> The plan is to provide a lower-level API that can easily be used to implement the higher-level API that is currently provided. This will also open the door to more easily building native-language Mesos libraries (i.e., not needing the C++ shim layer) and building new higher-level abstractions on top of the lower-level API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)