aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Stein <joe.st...@stealth.ly>
Subject Re: Seeking volunteers to create scheduler REST API RFC
Date Tue, 10 Feb 2015 03:26:41 GMT
Hey, this looks really interesting. We have been toying with "how do we run
frameworks on aurora" and I think that is a good use case for this also.

Can the pieces be broken up across a few different folks?

Can we preserve the thrift objects and have that also as an option (along
with json at least) to go over a http 2.0 end point?

~ Joestein

On Mon, Feb 9, 2015 at 5:31 PM, Brian Wickman <wickman@apache.org> wrote:

> +1
>
> On Mon, Feb 9, 2015 at 1:55 PM, Joshua Cohen <jcohen@twopensource.com>
> wrote:
>
> > I'd love to help out with this as well.
> >
> > On Mon, Feb 9, 2015 at 1:25 PM, Bill Farner <wfarner@apache.org> wrote:
> >
> > > Hi folks,
> > >
> > > Before embarking on work [1] to build a REST* API for the scheduler,
> it's
> > > important that we come up with a sound design.  Following up from
> today's
> > > IRC meeting, i would like to gather a small contingent (<=4 people) to
> > > collaborate on an RFC to drive a broader design discussion.
> > >
> > > Note that the RFC will be published to this mailing list, where it will
> > be
> > > completely open for discussion to change (it's a Request For Comments,
> > > after all).
> > >
> > > Volunteers must be willing to research the landscape for patterns and
> > best
> > > practices in designing web application APIs; prior experience in this
> > area
> > > is a plus.
> > >
> > > Several people volunteered in the IRC meeting, but to keep the
> canonical
> > > discussion in one place i ask those still interested to volunteer again
> > on
> > > this thread.
> > >
> > > I'll start by volunteering myself.
> > >
> > >
> > > -=Bill
> > >
> > > * Used as shorthand, whether it turns out to be REST, JSON-RPC,
> HATEOAS,
> > > etc.
> > >
> > > [1] https://issues.apache.org/jira/browse/AURORA-987
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message