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

Draft: Key expressions, first blog #29

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Conversation

p-avital
Copy link
Contributor

@p-avital p-avital commented Apr 7, 2023

This blog contains the following:

  • Short description of the KEL (including canonization),
  • A teaser for KeTrees, used as an excuse to present KEs as sets,
  • A set of rules to help users design better address spaces,
  • An introduction to KeFormats as a way to express address spaces.

@p-avital p-avital changed the title Key expressions, first blog Draft: Key expressions, first blog Apr 7, 2023
content/blog/2023-04-01-key-expressions-1.md Show resolved Hide resolved
content/blog/2023-04-01-key-expressions-1.md Outdated Show resolved Hide resolved
content/blog/2023-04-01-key-expressions-1.md Outdated Show resolved Hide resolved

# The KE Tree: a Zenoh flavoured data structure.

One thing you might have noticed is that with all these slashes, KEs definitely take after paths. One other aspect they take from paths is their intrisic hierarchical nature: like most good address spaces, KEs are hierarchical.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to think twice to understand the phrase "KEs definitely take after paths"

content/blog/2023-04-01-key-expressions-1.md Show resolved Hide resolved
1. If the KEs define disjoint sets (where there doesn't exist a key that belongs to both), they just don't interract.
2. If the operation KE and the existing data's KE define sets that have keys in common, like `a/*` and `*/b` both contain the `a/b` key, they are said to _intersect_. That means the operation will affect at least a subset of the existing data. Intersection is always symmetric: A intersects with B implies that B intersects with A.
3. If the operation KE's set contains all keys defined by the existing data's KE, the operation KE is said to _include_ the existing data KE. This means that the operation will affect _all_ of the existing data. Note that inclusion is generally asymmetric, but that "A includes B" or "B includes A" implies that "A and B intersect".
4. If the operation KE and data KE define the same set, they are equal. This is the only situation where inclusion is symmetrical, and thanks to our previously discussed [3 steps program](#specifying-the-kel), this is equivalent to string equality.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to our previously discussed 3 steps program -> can you now tell the truth that it was 4 steps ? :)

Copy link
Contributor Author

@p-avital p-avital Apr 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit-misread.

It's still called a "3 steps program" , that's just its name :p

content/blog/2023-04-01-key-expressions-1.md Outdated Show resolved Hide resolved
content/blog/2023-04-01-key-expressions-1.md Outdated Show resolved Hide resolved

Inclusion is a bit more "optimizy": if some writes to A that includes B and C, the records for B and C may be erased, since A has now taken over both of their regions on interest.

Equality and disjunction are generally not very useful: equality because inclusion is generally sufficient for most optimizations, and disjunction because it usually just means that two things do not care about each other, which we in turn don't care about.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this sentence would be better as a footnote

Copy link
Contributor Author

@p-avital p-avital Apr 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really disagree, considering it's not key information; it just feels more natural to me to include all 4 relations in the same flow rather than interrupting it with an indirection. Plus, I wouldn't really know where to put the footnote marker x)

content/blog/2023-04-01-key-expressions-1.md Outdated Show resolved Hide resolved
One of the major changes introduced by Zenoh 0.6 Bahamut was a new definition of the [Key Expression Language](https://github.com/eclipse-zenoh/roadmap/blob/main/rfcs/ALL/Key%20Expressions.md).
With Zenoh 0.7.1, we introduce new data structures that let you interact with this language more easily than ever before.

Come with me on a journey into Zenoh's vision of a Named Data Address Space: Key Expressions (KE). The major parts of this post are all rather independent, so feel free to skip past one if it's not to your taste.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

skip past one?
"if it's not your taste" looks better to me.

@kogratte
Copy link
Contributor

Was hard to read, but interesting.

Proposals available here (comments where not really usable :) ) : #31

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants