Global key/value in-memory storage

[ghost]

Feature Request

Bumblebee-status works in iterations. During an iteration, I would like to be able to save some data in a global in-memory key-value store, so I could use it in next iteration(s) (not necessarily in the same module, that's why it has to be global).

I am thinking about something as simple as an API with two functions:

bumblebee.storage.set(key, value)
bumblebee.storage.get(key)

for a global Python dictionary.

[tobi-wan-kenobi]

Implementation-wise, this would be very simple, but for the "cross module" functionality, I'd like to discuss use-cases, please.

There is a key/value store already for each module (each widget is one). The fact that this is not cross-module was intended to be a feature, not a bug. In my current view of modules/widgets, they should be self-contained, and anything that might "pollute" the space of one is dangerous.

Do you have anything specific in mind that needs this functionality?

[ghost]

I am fiddling with the idea of trying to make an animated graph widget using Braille characters, a bit in the spirit of https://github.com/chrisbouchard/braillegraph, but only one-row.

Technically, this would not require anything global, since the data could live inside a particular widget and be persistent iteration-wise. I am aware of this being possible after studying the traffic module, which I aim at chopping a little in the near future. But the way it is implemented there makes that lost in custom user-defined instance variable names.

I just thought that having an explicit interface like the one described above would make the code more readable. As for the risk of different modules overwriting the same key in the global storage - it's easily solved by prefixing key names with module name just like it's done for widgets:

bumblebee.storage.set("traffic.downdata", [1, 2, 3])  # download speeds for last three seconds
bumblebee.storage.get("traffic.downdata")

[tobi-wan-kenobi]

Ah, that sounds very interesting!

The widgets already give you exactly that interface, if you want it. Widgets derive from a "Store" class and they have "get()" and "set()" methods.

I think traffic even makes use of that. It's exactly for the reason you described - to not produce a large amount of member variables. And placing them inside the widget enforces the "namespacing", which otherwise would just be a convention.

Does that help?

⁣

On Jan 12, 2020, 15:11, at 15:11, somospocos notifications@github.com wrote:

I am fiddling with the idea of trying to make an animated graph widget using Braille characters, a bit in the spirit of https://github.com/chrisbouchard/braillegraph, but only one-row.

Technically, this would not require anything global, since the data could live inside a particular widget and be persistent iteration-wise. I am aware of this being possible after studying the traffic module, which I aim at chopping a little in the near future. But the way it is implemented there makes that lost in custom user-defined instance variable names.

I just thought that having an explicit interface like the one described above would make the code more readable. As for the risk of different modules overwriting the same key in the global storage - it's easily solved by prefixing key names with module name just like it's done for widgets:

bumblebee.storage.set("traffic.downdata", [1, 2, 3]) # download speeds for last three seconds bumblebee.storage.set("traffic.data", value)

-- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/tobi-wan-kenobi/bumblebee-status/issues/524#issuecomment-573419026

[ghost]

Widgets derive from a "Store" class and they have "get()" and "set()" methods.

Great, somehow this escaped me while skimming through the code. I will dive back into it one more time, before attempting to write anything. Feel free to close the issue for now then, it could be reopened later if there will be a need for it.