[
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162089#comment-14162089
]
Timothy St. Clair commented on MESOS-1330:
------------------------------------------
So a couple of comments on the design, I'll look over it again later but here
is my take thus far:
1.) raw pointers, just not a fan.
2.) The event manager abstraction appears to be conflated. It's role to me
seems to overlap with connection & process, but it seems kind of monolithic. I
think possibly breaking up the responsibilities would make it easier to follow.
3.) Any transitions around socket handling should probably start taking IPv6
into account, so we're not transforming it in the near future.
my 2ยข.
I'd be happy to hop on a hang-out, and chat in more detail.
> 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)
