[
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161456#comment-14161456
]
Dominic Hamon commented on MESOS-1330:
--------------------------------------
I'd love to see an abstraction layer to make it easier in future, but I prefer
these low-level pieces of the code to be more tightly bound to avoid
unnecessary overhead.
In other words, abstractions are great but when we're talking about the core
event loop for libprocess, I'd rather see a comparison of libev, libevent, and
libuv in terms of features and performance and then pick one. A lightweight
abstraction could make it easier to swap out again if something better comes
along, but we have to find the balance between abstraction, retaining features,
and avoiding overhead.
My understanding is that libevent has become something of a de facto standard,
so maybe that should be a focus for the abstraction, at least.
> Introduce connection/transport abstraction to libprocess
> --------------------------------------------------------
>
> Key: MESOS-1330
> URL: https://issues.apache.org/jira/browse/MESOS-1330
> Project: Mesos
> Issue Type: Improvement
> Components: general, libprocess
> Reporter: Niklas Quarfot Nielsen
> Assignee: Joris Van Remoortere
> Labels: libprocess, network
>
> I think it makes sense to think in terms of different low or middle layer
> transports (which can accommodate channels like SSL). We could capture
> connection life-cycles and network send/receive primitives in a much explicit
> manner than currently in libprocess.
> I have a proof of concept transport / connection abstraction ready and which
> we can use to iterate a design.
> Notably, there are opportunities to change the current SocketManager/Socket
> abstractions to explicit ConnectionManager/Connection, which allow several
> and composeable communication layers.
> I am proposing to own this ticket and am looking for a shepherd to
> (thoroughly) go over design considerations before jumping into an actual
> implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
