This is actually a pretty common problem and one you'll run into again and
again. The way I typically go about solving it is a Role to define teh API of
the various types of backends (SSH, cp, FTP) and then simple classes to define
each type. Something like:
package MyApp::TransferAPI { use Moose::Role;
requires qw(connect authenticate list get host user password remote_dir)
}
package MYApp::Transfer::FTP {
use Moose;
has [qw(host user password remote_dir)] => ( is => 'ro', required => 1);
has ftp_object => (
isa => 'AwesomeFTP', # made up for the purposes of this example
lazy => 1,
default => sub { AwesomeFTP->new( host => $self->host ... ) },
handles => [qw(connect authenticate get list remote_dir)]
);
with qw(MyApp::TransferAPI); # listed after has() becasue of reasons
}
is roughly how I'd approach this.
-Chris
On Fri, Sep 27, 2013 at 2:15 PM, Dan Cutler <dantcut...@yahoo.com> wrote:
> Hello Mooseketeers!
> I'm relatively new to Moose - I've built a nice Moose based app that I use
> in production.
> Now, I want to do something more complex. I want to abstract an interface
> (or similar) so that I can transfer files via FTP, SFTP or SCP (maybe even
> just "cp").
> To make it simple, I'd like to implement only a few of the methods - those
> around fetching files off some remote system where the protocol varies.
> The "get" type interfaces of all of these remote systems are very similar:
> connect
> authenticate
> ls
> get
> The attributes are also very similar:
> Host
> User
> Passwd
> RemoteDir
> So it seems I have many choices under the Moose umbrella:
> Roles
> Subclasses
> SubTypes
> Interface
> Others?
> The downline classes (Net::FTP, Net::SSH2) are obviously not Moose classes.
> But I can imagine my driver program looking extremely simple:
> my $remote_sys = MyAPP::Remote->new($attr_hash);
> $remote_sys->connect();
> $remote_sys->authenticate();
> $remote_sys->ls();
> $remote_sys->get();
> I've read many fine articles about all the various features and possible
> ways of coding such a critter. I've also been through many articles
> warning of how to "not" do things ;-)
> Could someone suggest a high level direction?
> I'd be happy to post my final example once I have it.
> Thanks!!
> --Dan
