Re: Streamlined application/script development [Re: coding an Application in perl]

On 05/09/17 10:54 AM, Chapman Flack wrote:
> On 09/01/2017 10:01 AM, Chapman Flack wrote:
>> On 09/01/2017 09:41 AM, Jean-Louis Martineau wrote:
>>
>>> 'directory' is not a good name, so if you get a better name, we can use it.
>> Hmm, destination? workspace? ...? Does that mean you would consider
>> changing it for all apps old and new in order to have it consistent?
> Ok, if destination only makes sense for restores - how about
> something like target? or object?

I like 'target', The change will include the amfetchdump --directory 
argument and many internal variable in the restore code.
For compatibility, application will accept bot directory and target.
Script will issue only target.
>
>>> I'm not sure that all the declare_*_options are required as everything
>>> 'backup' need must be accepted for all commands.
>> OK, I wasn't sure about that. There might still be extra 'restore'
>> properties, right? Because you can set those in an amrecover session.
> As I look at this more, I think the declare_*_options methods are
> still ok. They all call declare_common_options to set up the common
> ones, and the POD already recommends to put any new properties in
> declare_common_options, exactly because all commands need to know
> about them (with the possible exception of recover-time-only
> properties).
ok, you can keep them.
>
> So that leaves the only real differences between the other methods
> being the fixed API-specified options that differ (only backup can
> have --state-stream, only restore can have --dar, only estimate
> can have --level more than once, etc.) and those differences are
> real, yes?
YES, also --recover-dump-state-file is for restore only (Only used bu 
amgtar for now, but required for dar restore)
>
> Maybe the POD could be even more clear that most of these shouldn't
> be overridden in an application, it should only override
> declare_common_options and possibly declare_restore_options.
>
> While some of the other methods could be made "private" so an
> application /can't/ override them, I'm not sure that's worth
> the effort. There's a slightly different syntax to call them,
> so run() would then have to know which was which ... right now
> it just looks up 'declare_'.$subcommand.'_options' and calls it;
> I like simple. :)

I prefer it simple too.

Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone.  Instead, destroy it and notify me by reply e-mail