Comments (10)
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 thanrebase
?
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 thanrebase
?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.
Related Issues (20)
- go get fails HOT 13
- document release HOT 4
- libelektra-opts optional parameter args HOT 2
- libelektra-opts error codes HOT 2
- Java binding build warnings with JDK 20 HOT 2
- Unable to build docker images HOT 1
- spec plugin does not remove added meta data on arrays HOT 4
- [kdb] add support for `--profile` in `C` HOT 2
- [CI] Cirrus build job for documentation (PDF) fails after TeX Live update
- master build fails HOT 7
- testjna_gradle fails with: double free or corruption HOT 5
- Elektra hangs in kdbOpen HOT 2
- Cargo.toml change `bindgen` version HOT 1
- Rust bindings fail to build with stable (rustc 1.71.0) HOT 5
- upgrade Opensesame to libelektra 0.11.0 HOT 6
- Can't set value, `Did not find key ...` HOT 9
- removing an entry in array causes removing the whole array HOT 1
- rust elektra fails to build HOT 4
- Update docu about how to write release notes and fix commit msg from elektrabot HOT 8
- RISC-V: Build fails on v0.10.0 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libelektra.