On 3 czerwca 2017 at 19:09:26, Bart Schaefer (schaefer@xxxxxxxxxxxxxxxx) wrote: > I have no objection to including this module's functionality in the base > distribution. However, I don't think we should just chuck it in there > exactly as-is. > > Primarily, we should first decide where this should live in the module > hierarchy, i.e., what name should it have? > > For example would it be appropriate to put it under zsh/db/redis and Done that, sending patch to have basic concretes. Tests are difficult because they require a running redis with no password and databases 10 and 11 available for pruning and filling, etc. The test I send should be somehow disabled by default. > finally do the work of abstracting ztie out of db_gdbm? (I know this > supports some operations that the base ztie interface does not.) The -p option is "passthrough", disables read-cache on the parameter. Gdbm module can easily support this too. Then, -a is for in-arguments password, -A is password from file. It's not perfect that -p isn't password. "a" letter is for "authentication", so basic sanity is kept, but a new mnemonic word for no-cache option to free -p would be best. Cannot come up with any. Then there is the -f option. -a for "address" would be probably better, but it would harm current gdbm users. However it could be -f OR -a, users will easily learn that it's in general about address, which can be file in some databases. So maybe a clever outcome from this legacy-problems. For the abstract ztie, I should search builtintab for zrtie and zgtie (a new name for gdbm), and route the call? Earlier I was thinking about some libdl calls to check if a call is available and it was rather a show stopper. Searching builtintab could also lead to interesting approach – zsh/db module would allow to use custom implementations. Custom plugin-module would provide zrtie or zgtie and routing would work. To support older Zsh, custom module could detect if generic ztie is absent, and provide one. But current ztie isn't abstract, so loading pre-5.3.2 db/gdbm would block this. Rather a minor problem. > In that vein, this also introduces a question of whether zsh/db/ needs > to generically support a password mechanism. I'd suggest that it use > a parameter, possibly a hash with PM_HIDEVAL set whose keys are chosen > from arguments of ztie, but that's just a first reaction and probably > needs more thought. Unlike the naming decision, this doesn't need to > be determined before the module is otherwise integrated. So this would be a way to block direct zrtie and zgtie usage. It may be a good thing. Like with mkfs: if there wouldn't be mkfs.ext4, people or for sure I would take time to learn generic mkfs syntax. -- Sebastian Gniazdowski psprint /at/ zdharma.org
Attachment:
db_redis.diff
Description: Binary data
Attachment:
V12db_redis.ztst
Description: Binary data