Re: Meeting Minutes : Amanda Open Source Community

On 10/18/2018 09:28 AM, Dustin J. Mitchell wrote:
> While we did have a solid core of helpful power-users,
> substantial code-related participation was rare at best.  I think there
> were a variety of reasons for that, and some of the work we did aimed to
> change it (rewriting from C to Perl, and specifically the Application
> API).  But at least in my time it never really took off.

I had noticed that myself, and part of the explanation seemed to be
that the Application API left off a step early ... it defined the
interprocess message formats between the participating processes,
but the only Perl modules/classes you could use or inherit from
did not make it very easy to use any of that; your barrier to entry
for writing a new 'application' or 'script' was that you still
pretty much had to master the IPC message formats and roll your own
code to generate and parse them.

I did some work 2016 - 2017 aimed at taking that application/script
API the rest of the way and make it easier for a non-core hacker to
put together an application or script. That's currently pull request
#78 on the GitHub mirror:

https://github.com/zmanda/amanda/pull/78

It has a much more detailed intro/rationale that I won't copy/paste
here.

>  * Put the code on Github.  Maybe it feels like selling out, but that's a
> massively lower bar to entry than sourceforge / svn. 

+1 on this ... I think at the time I made the above GitHub pull
request, I thought I was making my contribution easy to integrate;
I am not sure I understood at the time that the GitHub repo was a
downstream mirror, and my pull request there just meant work for JLM
to convert it to svn commits.

>    * Provide a simple, well-tested getting-started-hacking guide

There is a bunch of new documentation on application/script hacking
included in the above pull request - there's a generated PDF of the
doc attached to the request. (Also, in the course of doing the
work, a bunch of vague or incompletely specified things in the wiki
docs turned up, and some of those JLM has already fixed on the wiki).

> Somewhat longer-term, it might be good to talk about what Amanda wants to
> be.  Amanda's *old* - 26 years old!  What is its specialty in the modern,
> cloud-driven era?

I actually think that the application/script API is a meaningful
distinction for Amanda (especially if it can be made more approachable
so more people can use it). If you know enough about the stuff you're
backing up to know there are properties of the data or layout that
you can take advantage of, or particular ways the backup process needs
to interact with the generating process to make sure you get a clean
backup, you can write some lines of Perl to make all that happen, and
it all gets administered and controlled in the familiar Amanda way,
together with whatever other systems you're backing up.

That's certainly how I'm using it at $work. I'm not aware of other
systems offering that particular kind of flexibility.

I would be happy to resume some work on that pull request if there's
a chance to get it integrated. If I remember right, JLM had asked me
to handle the DIRECTORY (now TARGET) property differently, as what
I had guessed from the documentation didn't quite match how he meant
for things to work.

https://marc.info/?l=amanda-hackers&m=150428762720212&w=2
https://marc.info/?l=amanda-hackers&m=150429295921889&w=2
https://marc.info/?l=amanda-hackers&m=151120396810173&w=2

I think I didn't hear back after that last one, and then I had other
things to do, and you know how it goes. But I think that's the point
where it left off and I could pick it back up again.

-Chap