The general recommendation for working with protobuf is to avoid required but put the check in the runtime logic. This allows the protocol to change down the road much easier.
I know we haven't done that in the past but the weight of community suggests we should consider it. On Feb 13, 2015 4:14 PM, "Benjamin Mahler (JIRA)" <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/MESOS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14321023#comment-14321023 > ] > > Benjamin Mahler edited comment on MESOS-1127 at 2/14/15 12:14 AM: > ------------------------------------------------------------------ > > Another request: Currently {{TaskStatus}} has an _optional_ SlaveID. This > complicates things because reconciliation requests consist of TaskStatuses, > and so the master is sometimes forced to create status updates without a > SlaveID. > > In Event/Call, {{Acknowledge}} require SlaveID which means that schedulers > need to infer that absence of a SlaveID in a TaskStatus means it needs no > acknowledgement. Bit of a mess that I'd love to see cleaned up by making it > required! > > > was (Author: bmahler): > Another request: Currently {{TaskStatus}} has an _optional_ SlaveID. This > complicates things because the reconciliation reply accepts TaskStatuses, > and so it is sometimes forced to create status updates without a SlaveID. > In Event/Call, acknowledgements require SlaveID which means that schedulers > need to assume that the absence of a SlaveID in a TaskStatus means it needs > no acknowledgement. Bit of a mess that I'd love to see cleaned up by making > it required! > > > 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) >
