> > I thought the low-level api being referred in the > video had to do with communication between master and framework|executor > for scheduling. But, it's really administrative. I thought that would > have been an opportunity for a Go binding that did not require the C++ > libraries. >
Vladimir, the low-level API referred to in the talk is exactly what you're interpreting, it is for communication between master and scheduler, and slave and executor. You could definitely build pure go bindings as you described, just not with JSON. Forget I mentioned anything about the administrative endpoints and JSON, as I see that's leading to confusion. ;) On Wed, Apr 9, 2014 at 3:39 AM, Vladimir Vivien <vladimir.viv...@gmail.com>wrote: > Ben, > Thank you for clarifying. I thought the low-level api being referred in the > video had to do with communication between master and framework|executor > for scheduling. But, it's really administrative. I thought that would > have been an opportunity for a Go binding that did not require the C++ > libraries. > > Thanks anyway. > > > > > > > On Tue, Apr 8, 2014 at 4:52 PM, Benjamin Mahler > <benjamin.mah...@gmail.com>wrote: > > > Sorry, I was not referring to implementing a scheduler via JSON instead > of > > protobuf, in theory that would be possible but there has been no planning > > in this area. Sorry for the confusion. > > > > I was referring to administrative endpoints. For example, kicking a > > framework out or telling the master a slave is needs to be repaired. > These > > endpoints may rely on the ability to convert JSON to internal protobufs. > > > > Can you clarify what you're looking to do? Are you looking to implement > an > > API in Go that communicates with JSON instead of serialized protobuf? > > > > On Tue, Apr 8, 2014 at 1:19 PM, Vladimir Vivien > > <vladimir.viv...@gmail.com>wrote: > > > > > Ben, > > > That is exactly what I am asking. > > > Is that something coming up soon, is there a JIRA I can look at? > > > I wanna get early start on a native json Go api or even help out if > > > possible. > > > > > > > > > On Tue, Apr 8, 2014 at 3:25 PM, Benjamin Mahler > > > <benjamin.mah...@gmail.com>wrote: > > > > > > > +vinod, benh > > > > > > > > Hey Vladimir, there will be some authenticated REST endpoints at some > > > > point, there is some work in this area underway. > > > > > > > > We have the ability to encode protobuf messages as JSON, so the plan > > was > > > to > > > > have any REST endpoints directly use JSON to send us protobuf > messages. > > > I'm > > > > not sure if this is what you're asking though? > > > > > > > > > > > > On Tue, Apr 8, 2014 at 11:13 AM, Vetoshkin Nikita < > > > > nikita.vetosh...@gmail.com> wrote: > > > > > > > > > I'm not a mesos guy, just very curious. But in my opinion - I doubt > > it, > > > > > HTTP is synchronous request-response protocol. Mesos needs > something > > > more > > > > > robust for message passing. Websockets anyone? :) > > > > > > > > > > > > > > > On Tue, Apr 8, 2014 at 10:08 PM, Vladimir Vivien > > > > > <vladimir.viv...@gmail.com>wrote: > > > > > > > > > > > Ben / Nikita > > > > > > Thanks for the pointers. > > > > > > So, (without digging yet) is it a fair summary to say that > > libprocess > > > > > wraps > > > > > > protobufs-encoded calls and push them over HTTP to master/slaves > ? > > > Will > > > > > > protobuf (eventually) be supplanted by direct HTTP via REST or > > > similar > > > > ? > > > > > > > > > > > > > > > > > > On Mon, Apr 7, 2014 at 2:54 PM, Vetoshkin Nikita < > > > > > > nikita.vetosh...@gmail.com > > > > > > > wrote: > > > > > > > > > > > > > Or, just to get to know - you can take tcpdump and take a look > :) > > > > > > > > > > > > > > I personally wouldn't call that HTTP. Something "HTTP-like" > would > > > > > > describe > > > > > > > it better. Because it's not request-response. It's just message > > > > > passing, > > > > > > no > > > > > > > need to wait for the answer - send new message one after > another. > > > > Every > > > > > > > message is POST with address and message type encoded in URI: > > POST > > > > > > > /executor(1)/mesos.internal.RunTaskMessage. Sender is encoded > in > > > > > > User-Agent > > > > > > > header, e.g: libprocess/slave(1)@127.0.0.1:5051. Body contains > > > > > protobuf > > > > > > > message, Transfer-Encoding is always "chunked". > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 7, 2014 at 10:42 PM, Benjamin Mahler > > > > > > > <benjamin.mah...@gmail.com>wrote: > > > > > > > > > > > > > > > Unfortunately you will need to learn this by looking at the > > code > > > in > > > > > > > > libprocess, as the message passing format is not explicitly > > > > > documented > > > > > > at > > > > > > > > the current time. > > > > > > > > > > > > > > > > Start with calls like ProtobufProcess::send() and dig your > way > > > > down. > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Apr 5, 2014 at 7:52 AM, Vladimir Vivien > > > > > > > > <vladimir.viv...@gmail.com>wrote: > > > > > > > > > > > > > > > > > I was watching this video from > > > > > > > > > https://www.youtube.com/watch?v=n5GT7OFSh58from Ben where > he > > > > > talked > > > > > > > > > about the wire protocol for Mesos being done in > > > > > > > > > HTTP. > > > > > > > > > > > > > > > > > > Where can I learn about the low-level wire protocol either > in > > > > > > > > documentation > > > > > > > > > or browsing through the code. > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Vladimir Vivien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Vladimir Vivien > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Vladimir Vivien > > > > > > > > > -- > Vladimir Vivien >
