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

Hi Jean-Louis,

Following the most recent commits that I added to pull request #78
last week, I think the only work left for me to do from our earlier
discussion is to implement local state for scripts, as we talked
about here:
  https://marc.info/?l=amanda-hackers&m=150430373325284
as a prerequisite for changing scripts to use the TARGET property
as you intended.

Before I can do that, I need a way of storing script state safely
under possible concurrency; it will be trickier than for application
state. One easy solution would be to use DBD::SQLite ... even if only
using SQL to save a simple blob of JSON, say, SQLite easily solves
the concurrency and durability requirements that I would otherwise
have to code some one-off tricky solution for.

I notice that you are now adding Catalog code that can require
DBD::SQLite or another database backend, but on the server.
If I were to use it for script state, it would become a dependency
on clients too. (It could be a conditional dependency, only for
clients that will use scripts based on Amanda::Script::Abstract
and that use local state.)

So I am wondering if that will be ok, before I start coding on this
last part of the work we discussed.

Thanks,
-Chap


On 11/01/2017 11:37 PM, Chapman Flack wrote:
> On 10/23/17 17:52, Chapman Flack wrote:
>> On 09/13/2017 01:10 PM, Jean-Louis Martineau wrote:
>>
>>> Amanda already require the perl JSON module, so you can use it.
>>
>> I notice you are adding some recent code that may use DBD::SQLite
>> for catalogs. Is that becoming ok to depend on now? On a server
>> only, or server and client?
> 
> This question is more or less on my critical path now, because of the
> various review comments on the pull request, state management for
> scripts (exploiting the new server session timestamp) is about the only
> one remaining for me to work on.
> 
> Local state for applications was relatively simple (each one just
> keeps its own file per DLE), but if scripts are to be able to cache
> state per session-timestamp (and somehow efficiently see and manage
> expired cached states), and possibly set properties for later-running
> scripts in the session, a shared file with better concurrency-control
> properties might be desirable. That would come essentially for free
> with SQLite, if it is already expected to become a dependency anyway.
> 
> -Chap
>