implement rename plugin about libelektra HOT 10 CLOSED

needed for openicc support

from libelektra.

The rename plugin is a filter plugin that modifies the names inside a backend.

The core functionality is to:
1.) pop and duplicate keys where renaming is necessary
2.) remember the original name in the metakey "name"
3.) change the name according to rules below
4.) in the way back restore the name according the metakey "name"

The plugin should be implemented in lua, python and C/C++ for benchmarking.

@manuelm: Any consideration for the C/C++ plugin?

The name changing rules are:

rebase

rebase: remove/add a common prefix after parentKey
cut of common basename below mountpoint)

e.g. with plugin config

rebase=org/freedesktop/openicc

we would rename:

system/org/freedesktop/openicc/org/freedesktop/openicc/device

to

system/org/freedesktop/openicc/device

Make sure to not cut off pieces of the parentKey's name.

trim

remove spaces in the name (that are not part of parentKey!)

case

upper/lowercase the name (that are not part of parentKey!)

Allows to make backends case insensitive (+preserving).

from libelektra.

I have some questions regarding the implementation:

• general: What about using MetaKeys to control which keys are affected by alterations? This would be way more flexible than using the plugin configuration
• rebase: if rebase= removes from the passing keys, which configuration is required to add parts? Wouldn't it be better to have two different configurations: rebase/add= adds a name to the beginning, while rebase/remove= strips ?
• trim: which spaces? Just at the beginning / end?

from libelektra.

Felix Berlakovich wrote:

I have some questions regarding the implementation:

• general: What about using MetaKeys to control which keys are affected by
  alterations? This would be way more flexible than using the plugin
  configuration

I am open to a more general solution. It should be configurable using kdb mount though. Could you please elaborate?

• rebase: if rebase= removes from the passing keys, which
  configuration is required to add parts? Wouldn't it be better to have two
  different configurations: rebase/add= adds a name to the beginning,
  while rebase/remove= strips ?

See src/plugins/yajl/yajl/OpenICC_device_config_DB.json

In there they repeat the org/freedesktop/openicc prefix where the stuff is
mounted to.

That means, during reading the file (kdbGet), the org/freedesktop/openicc needs
to be cut away, but before writing the file (kdbSet) the same stuff needs to be
appended again.

Admittedly, rebase is still not a perfect name. But having two different
options would be error prone for the usecase. And I do not have any usecase
where add/remove would be different.

Maybe the name cut is better than rebase?

• trim: which spaces? Just at the beginning / end?

Yes, just whitespaces at beginning+end of every key name part.

Another interesting thing would be do convert between different name styles,
e.g.:

• space exif manufacturer
• lisp exif-manufacturer
• C exif_manufacturer

Basically all those features are optional. Only rebase/cut is really needed at
the moment.

best regards

from libelektra.

I am open to a more general solution. It should be configurable using kdb mount though. Could you please elaborate?

I was thinking of using MetaKeys as it is done in the validation plugin or keytometa. glob could add a MetaKey to each key to be rebased. The simplest case would be to add the MetaKey to all keys, but sometimes it might be useful to cut only some of the keys. However, fully configuring glob during the mount is not possible (because MetaKeys need to be added to the config keys) and therefore I would suggest providing both possibilities. The config option you suggested could simply be a shortcut for cutting all keys. But once the cut logic is in place, extending it to Keys tagged with MetaKeys should not be hard.

Maybe the name cut is better than rebase?

Cut sounds good. I cannot provide a useful case for add either and therfore I will leave it out for now.

Basically all those features are optional. Only rebase/cut is really needed at the moment.

Ok. But as it seems, many useful rename variants exist and therefore I will strive for a solution that allows easy extension in the future. This speaks for C++ even more.

from libelektra.

Hello,

Felix Berlakovich wrote:

I was thinking of using MetaKeys as it is done in the validation plugin or
keytometa. glob could add a MetaKey to each key to be rebased. The
simplest case would be to add the MetaKey to all keys, but sometimes it
might be useful to cut only some of the keys. However, fully configuring

Yeah it certainly is useful to allow globbing; e.g. if there are some keys
next to org.freedesktop that should not be renamed. But please keep it simple
to configure ;)

glob during the mount is not possible (because MetaKeys need to be added
to the config keys) and therefore I would suggest providing both
possibilities. The config option you suggested could simply be a shortcut

Maybe we can transform glob's configuration to metakeys easily so that the
problem of configuring glob is gone completely? (afaik glob is the only plugin
with this requirement) That would solve similar issues in keytometa, too.
Otherwise, providing both ways are the most sensible way.

for cutting all keys. But once the cut logic is in place, extending it to
Keys tagged with MetaKeys should not be hard.

Perfect!

Maybe the name cut is better than rebase?

Cut sounds good. I cannot provide a useful case for add either and therfore
I will leave it out for now.

Yeah, it is dangerous to have transformations that would modify the
keydatabase after every

kdbGet();
kdbSet();

Basically all those features are optional. Only rebase/cut is really
needed at the moment.

Ok. But as it seems, many useful rename variants exist and therefore I will
strive for a solution that allows easy extension in the future. This

That is the spirit, thank you!

speaks for C++ even more.

String resizing isn't really the strength of C (w/o a library). On the other
hand C++ streams can be very expensive. I do not use dump for benchmarks
because of this. For openICC the renaming would be the only part of the
pipeline in C++, though.

from libelektra.

We reuse a addprintf() function to work with strings in many projects. It takes care of string length, appending, allocation and uses printf internally. So for simple operations outside of substitution of a regex it could be easy in C. Just an idea.

from libelektra.

Yeah, something similar already exists in ELEKTRA_SET_ERRORF and
ELEKTRA_ADD_WARNINGF. It only reallocates when the buffer is not large enough.

On more thing: For plugins in C++ quite an amount of boiler plate is needed if
you want the plugin nicely as class. This boiler code is already duplicated
about twice ("tcl" and "type" plugins iirc). Would be nice to have that in a
library ;)

from libelektra.

On more thing: For plugins in C++ quite an amount of boiler plate is needed if you want the plugin nicely as class. This boiler code is already duplicated about twice ("tcl" and "type" plugins iirc). Would be nice to have that in a library ;)

Which boiler plate do you mean? I cannot see too many similarities between tcl and type. If performance is a concern and the C++ plugins need cleanup, maybe it would be better to implement it in C. Especially cutting strings shouldn't be too hard even in C.

from libelektra.

Hello,

You wrote:

Which boiler plate do you mean? I cannot see too many similarities between
tcl and type.

Ohh, its type and struct. Basically everything in type.cpp and struct.cpp is
the boiler code and quite duplicated. In C++ one would expect to just write a
class that registers itself as plugin.

If performance is a concern

C++ can be used in situations where high-performance is required, too. In some
situations it is even superior to C, e.g. when using exceptions for situations
that practically never occur (at least when compared to using "if" for every
return code).

and the C++ plugins need cleanup,

The next plugin using a c++-class should not repeat the same mistake ;)
I can help you with the Plugin registration.

C++ can be used completely without a plugin class: e.g. dump and tcl, too.
Then the mentioned problem would not exist.

maybe it would be better to implement it in C. Especially cutting
strings shouldn't be too hard even in C.

It is your decision. I am completely ok with every of these solutions.

best regards

from libelektra.