Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve directoryvalue #3256

Open
kodebach opened this issue Nov 20, 2019 · 1 comment

Comments

@kodebach
Copy link
Contributor

@kodebach kodebach commented Nov 20, 2019

In #3223 I proposed a change to directoryvalue, that would avoid the possible collisions that the base name __directoryvalue could cause. The proposed version would probably work fine, but I had a better idea.

Storage plugins have to have some mechanism to store metadata. So why not move the problematic key's value into metadata?

This might seem like we are just moving the problem, but we are not. There is already precedence for metakeys having special semantics. For example, the way origvalue works, means that it can never occur in a stored config file.

Now, we could either abuse the origvalue name to avoid conflicts, or we could just define that e.g. dirvalue must not be used for actual metadata. Then the directoryvalue plugin could store the problematic keys' values into dirvalue metakeys.


I also still think, that directoryvalue should be a library not a plugin. Libraries are more flexible. If the library just provides a function elektraIsDirectoryKeyWithValue (Key * k, KeySet * ks), then plugins could do whatever suits them best with these keys. Some plugins might not need to move the value, but instead just need to store it differently.
A library would also avoid the overhead related to creating/reading mountpoints.

@markus2330

This comment has been minimized.

Copy link
Contributor

@markus2330 markus2330 commented Nov 20, 2019

I do not see how metadata can help here. The purpose of directoryvalue is circumvent limitations of configuration file formats, so it needs to encode data within key names and key values, as no other place is available to store the additional information.

The only "problem" directoryvalue has is that it would not work if someone actually would like to store __directoryvalue. As this is quite unlikely, I accepted the plugin.

I also still think, that directoryvalue should be a library not a plugin.

This makes writing of storage plugins even harder as it already is. The advantage of directoryvalue as plugin is that it works completely transparent. The storage plugin gets the guarantee that the directories will not have values and do not need to do anything to handle these situations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.