[
https://issues.apache.org/jira/browse/MESOS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1891:
----------------------------------
Description:
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.
was:
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 something like this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual void initialize(const process::UPID& clientPid) = 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.
> 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)
