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

GNOME Integration: decision to GSettings values #768

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@raetiacorvus
Contributor

raetiacorvus commented Jun 2, 2016

Decision on how to handle GSettings values when using Elektra as
backend.

GNOME Integration: decision to GSettings values
Decision on how to handle GSettings values when using Elektra as
Backend.

@markus2330 markus2330 added the proposal label Jun 2, 2016

- `Elektras` strength is its modularity to provide multiple backends that decide how to save values
- `GVariants` can be printed as Strings and parsed back again if we know the type
- `GVariants` can be also serialized and deserialized
- representing `GVariants` values trough strings fulfills all three constraints

This comment has been minimized.

@markus2330

markus2330 Jun 2, 2016

Contributor

two line above it says that you need to know the type, so do you need meta-data, too?

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 2, 2016

Contributor

No GSettings tells me what type it expects

## Decision
- Use GVariants string representation

This comment has been minimized.

@markus2330

markus2330 Jun 2, 2016

Contributor

Is the string representation of basic types (int, bool) compatible with Elektra's types?

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 2, 2016

Contributor

boolean is repesented as 'true', 'false' that would need the convenience plugin globally to work with elektras c++ api.
Everything is a pure string even integers.

And i also do not want to do type conversion as it would be inconsistent with other GVariant types. like nested arrays of boolean for example.

If we would start doing that we would have to write our own GVariant converter, which is probably enough work for another thesis.

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 2, 2016

Contributor

The idea is also to keep this layer as thin as possible and add needed functionality as plugins to Elektra.

This comment has been minimized.

@markus2330

markus2330 Jun 2, 2016

Contributor

It was more as a question, the implication should describe how compatible the gvariants types are to other types and which additional plugins would be needed.
(It does not mean you have to write every plugin related to types)

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 2, 2016

Contributor

Yes. You are right i probably should elaborate this problem better. I have to admit i totally forgot about Elektras c++ api and types while using the glib binding which are nearly identical as using the c api. Because of that I am probably also still lacking the proper knowledge about Elektras behavior with different types. This also brings up my question how the different plugin handle 'true' and 'false' strings. But I would rather like to discuss that at our next meeting so everyone benefits from it. I am already putting together a list inside #762 regarding other questions.

Again thank you for you thorough feedback, and sorry for my sometimes harsh answers.

## Argument
GVariants string representationat is the most useful for all parts involved. It is immediately human readable and usable in code trough string compares.

This comment has been minimized.

@markus2330

markus2330 Jun 2, 2016

Contributor

typo: representationat

We could consider to save the GVariant type as metadata, but would prefer to keep metadata at a minimum.
GVariant offers to print additional type info included to the string but this defeats the purpose of having a
value that is easily human readable and the output seems to be only generated in special cases e.g. if an int is unsigned

This comment has been minimized.

@markus2330

markus2330 Jun 2, 2016

Contributor

These are not notes, but important parts of the decision.

GNOME Integration: update decicion to GSettings
fix typos, elaborate the type situation better
be more detailed in constraints, asumptions, decisions as well as
argmuments, consider further influences of other decicions on this one.
- `Elektras` strength is its modularity to provide multiple backends that decide how to save values
- applications using `GSettings` are well aware about the types they use
- `GVariant` types can be represented as strings

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

As discussed: maybe link some material or give some more information about their representation.

- `Elektras` strength is its modularity to provide multiple backends that decide how to save values
- applications using `GSettings` are well aware about the types they use
- `GVariant` types can be represented as strings
- `GVariant` types are rather self explaining about their type to some degree e.g. (255, 144) is a tuple of int

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

I thought there are some ' quotes?

This comment has been minimized.

@raetiacorvus

raetiacorvus Jun 13, 2016

Contributor

I only realized it after writing this document. I should update the information.

- `GVariant` string representation can be parsed back into a `GVariant` reliable if we know their type
- `GVariant` string representation can be parsed back into a `GVariant` unreliable on type guessing by parsing
- `GVariant` can be serialized and deserialized, meaning it is possible to save all types binary
- `Elektra` offers types trough templates in its c++ api

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

misspelled "through"

Elektra also has type definitions in C (kdbtypes.h), only the type checker (currently) is implemented in C++.

- use GVariants string representation
- do not use GVariants additional type information in the string
- do not use type mapping in the `GSettings` backend layer
- keep usage of metadata as minimal as possible in favor of portability

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

That is a constraint, not a decision. As decision we would be interested to know which meta data it should use.

## Decision
- use GVariants string representation
- do not use GVariants additional type information in the string

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

Yes, good idea. But we should store them in some meta-data, ideally directly type, otherwise gvariant with the letters encoding the gvariant-type.

GVariant offers to print additional type info included to the string but this defeats the purpose of having a
value that is easily human readable and the output seems to be only generated in special cases e.g. if an int is unsigned.
Serialized values would either create a dependency on `GVariants` deserialization or need a custom implementation in Elektra.

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

How is this different to string serialization?

Btw. it would not matter if some plugins depend on GVariants.

Serialized values would either create a dependency on `GVariants` deserialization or need a custom implementation in Elektra.
Without one of both they would not be human readable.
Direct mapping to `GVariant` would need `spec` to always be up to date and changes in types could break the mapping.

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

Which would work by mounting the schemata to spec.

The meta-data can applied to every namespace, its not specific to spec. But not every storage plugin is capable of storing meta-data, but this can be fixed with a metatostring plugin.

Direct mapping to `GVariant` would need `spec` to always be up to date and changes in types could break the mapping.
In addition it will be hard to match all possible `GVariant` types.
The idea is also to keep the `GSettings` backend layer as thin as possible and handle further problems in `Elektra` itself.

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

That is also a constraint. And I fully agree with it!

## Related decisions
This influences the future follow up decision on how to handle defaults and constrains of GSettings in Elektra.

This comment has been minimized.

@markus2330

markus2330 Jun 10, 2016

Contributor

I am afraid its not easily possible to separate the decisions, also here we already need to know where to get the type from.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 13, 2016

Can I merge it?

@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jun 13, 2016

Sorry i did not have time yet to read over your new feedback.

@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jun 13, 2016

I think i need time to do a rework after we are trough with the surveys issues.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 13, 2016

Ok, do not worry, lets keep it open. It is not urgent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment