[
https://issues.apache.org/jira/browse/MESOS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174711#comment-14174711
]
Till Toenshoff commented on MESOS-1891:
---------------------------------------
https://reviews.apache.org/r/26857/
> Authenticator Module: Interface design
> --------------------------------------
>
> Key: MESOS-1891
> URL: https://issues.apache.org/jira/browse/MESOS-1891
> Project: Mesos
> Issue Type: Improvement
> Components: modules
> Reporter: Till Toenshoff
> Assignee: Till Toenshoff
> Priority: Blocker
>
> h4. Motivation
> Design an interface covering authenticator modules while staying minimal
> invasive in regards to changes on the existing flat-file Authenticator
> implementation.
> h4. Status Quo
> The current sasl based, "flat-file" Authenticator (
> {{sasl/authenticator.hpp}} ) is spawning a (libprocess) process in its
> constructor and demands the authentication client process UPID as a parameter
> - not a perfect fit for the current Module API as that one does only allow
> default constructors.
> h4. Design
> Instead of wrapping the flat-file Authenticator with yet another class that
> satisfies a proper interface design, we might just as well slightly change
> the current design into a feasible interface, no?
> I would like to propose this:
> {noformat}
> class Authenticator
> {
> public:
> Authenticator() {}
> virtual ~Authenticator() {}
> virtual Option<Error> initialize(const process::UPID& clientPid, const
> Option<Credentials>& credentials) = 0;
> virtual process::Future<Option<std::string> > authenticate(void) = 0;
> };
> {noformat}
> As a result, the flat-file authenticator would spawn its process within that
> proposed initialize method and not within the constructor already.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
