Could you elaborate on the benefits? What's the motivation behind this being a general recommendation (any pointer to this)? Which kind of things does this make easier?
The downside is that we lose the signal telling frameworks what to set, and we're left with: optional Foo foo; // required On Fri, Feb 13, 2015 at 4:56 PM, Dominic Hamon <[email protected]> wrote: > 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) > > >
