Something to think about: Transaction logic
The current specification allows Pulley to continue sending pulleyback_add()
and pulleyback_del()
in case of transaction failure. It demands that the plugin then returns 0. This protocol leads to repeated work in all plugins, which now need to remember and test whether the transaction failed.
A simple redesign would be a guarantee that after a failure in pulleyback_add()
or pulleyback_del()
or pulleyback_prepare()
, the next call would always be pulleyback_rollback()
.
The following may actually work already: Similarly, the transaction logic in plugins may now have to invoke pulleyback_prepare()
if it wasn't called yet. If the function is available, it's probably best to guarantee that it will be called before pulleyback_commit()
or pulleyback_rollback()
.