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

I'm working on a new features where the command_backup will get feedback 
from the server to get a confirmation the backup is secured on 
holdingdisk/tape.
Updating the statefile must be done after that.

To ease the merge, can you split inner_backup in two methods: 
inner_backup() and backup_update_state()
command_backup should call them sequentially for now.

You sometimes use fdout and sometimes outfd, can you always use the same 
(fdout)
Same thing for fdin and infd.
outfd and infd are only in perl/Amanda/Application/Abstract.pm

Jean-Louis

On 01/09/17 09:41 AM, Jean-Louis Martineau wrote:
> More comments
>
> The 'directory' property is special, it is where all commands do their 
> action, it is used instead of the --device.
> This is also where the restore go.
> But it is not always a directory, it can describe some remote path 
> (smb share, vm, ...)
> I want all applications to use the same property name.
> That's why your new application must support 'directory' instead of 
> 'filename'.
> The Abstract class should not check if 'directory' is a directory.
>
> 'directory' is not a good name, so if you get a better name, we can 
> use it.
>
> I'm not sure that all the declare_*_options are required as everything 
> 'backup' need must be accepted for all commands.
>
> Jean-Louis
>
>
>
> On 30/08/17 11:31 AM, Jean-Louis Martineau wrote:
>> I started to look at the command_support.
>>
>> Why $say_supports is a variable instead of a sub?
>>
>> In $say_supports, why to you blessed($self)? Why not just use $self?
>> Something like:
>>
>>     sub supports {
>>         my ($self, $supname ) = @_;
>>         my $s = $self->can("supports_".$supname);
>>         return (defined $s) and $s;
>>     }
>>
>>     sub say_supports {
>>         my ( $self, $confstring, $supname ) = @_;
>>         my $yn = $self->supports($supname) ? "YES" : "NO";
>>         print $confstring . " " . $yn . "\n";
>>     }
>>
>>
>> jean-Louis
>>
>> On 12/08/17 12:59 PM, Chapman Flack wrote:
>>> On 06/05/17 17:03, Chapman Flack wrote:
>>> > On 06/02/2017 02:07 PM, Chapman Flack wrote:
>>> >
>>> >> I am nearly at the point of pushing this stuff to a github fork
>>> >> for possible eventual consideration. It has been running for me
>>> >> in actual backups for the better part of a year (down to a month
>>> >> or two for the newest scripts), so there is experience behind it.
>>>
>>> https://github.com/zmanda/amanda/pull/78 
>>> <https://github.com/zmanda/amanda/pull/78>
>>>
>>> I think this could significantly simplify development of new
>>> Amanda applications and scripts, enough that more 'ordinary' Amanda
>>> users (who are not -hackers) could approach creating and sharing them
>>> for special backup circumstances they face. I hope, with more people
>>> able to contribute and a less steep learning curve, it can lead to more
>>> progress on the list of proposed applications on the developer Tasks
>>> wiki page!
>>>
>>> Cheers,
>>> -Chap
>>
>>
>
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