Change Details

Currently, `kbx/backend-sqlite.c` uses three phase setup for `info_cb` with `dotlocK_create`, `dotlock_set_info_cb` and `dotlock_finish_create` . This can be done with, say, `dotlock_create_with`, supplying the call back function. And, we can change the semantics of call back function to be responsible to all about emitting message. (Currently, it could only handle specific reason, `kbx/backend-sqlite.c` only handles `DOTLOCK_WAITING`)

Currently, `kbx/backend-sqlite.c` uses three phase setup for `info_cb` with `dotlock_create`, `dotlock_set_info_cb` and `dotlock_finish_create` . This can be done with, say, `dotlock_create_with`, supplying the call back function. And, we can change the semantics of call back function to be responsible to all about emitting message. (Currently, it could only handle specific reason, `kbx/backend-sqlite.c` only handles `DOTLOCK_WAITING`)

Currently, `kbx/backend-sqlite.c` uses three phase setup for `info_cb` with `dotlocKk_create`, `dotlock_set_info_cb` and `dotlock_finish_create` . This can be done with, say, `dotlock_create_with`, supplying the call back function. And, we can change the semantics of call back function to be responsible to all about emitting message. (Currently, it could only handle specific reason, `kbx/backend-sqlite.c` only handles `DOTLOCK_WAITING`)