Get the first draft up there

[teamcons]

• draft json_storage
• draft string_storage
• set up a demo code for testing
• make json dependency optional (meson option)
• explain how to add libfridge to a flatpak manifest (with/without option)
• include the meson thingamabobs to have this built on window
• Add is_empty() and contains()
• Add read_only
• Add delete
• Make content property non nullable.
• Add a rename() method
• ??draft byte_storage (Wait i thought we could just writedump a bunch of binary)
• test extensively
• Review documentation and make it as clear as possible
• first release

[teamcons]

@colinkiama id love your input and help here and there :) Ive got my head in a lot of community projects already, and this is all very new to me

[colinkiama]

For testing purposes, Taking advantage of meson’s test features would be convenient. These could run in CI actions too! For example: https://github.com/vala-lang/vala-lint/tree/master/test

[teamcons]

Probably. I was thinking of doing a local fork of the Slate app (text editor that saves in data unsaved files), so there is a everyday testing we can do

[colinkiama]

Let’s say I do the following things in an app:

• Start new instance of app
• Create a StringStorage instance
• Save data on that instance
• Restart the app
• Create a new StringStorage instance
• Save data to that instance

What happens? Would there be a file clash? (trying to overwrite an existing file)

[teamcons]

mhm, yes by design. If you dont name your storages, it falls back on the dynamically allocated ones
So your first storage declared will always be the first one, ....your n-th storage declared will be the nth one

so if you declare three storage instances, but always load and save from the third one, it will still be the same one. Since your apps code will always create the instance in the same order anyway and therefore refer to the same files in the same order

so whether you call it "storage" or "flurp" or nothing (aka the auto one), you still load and save from the same one with whatever variable name you gave it.

It would be better if someone declare a file name for their storage and stands by it. But this way people can not bother, identify their object by their variable name, and it automagically follows the same order of declaration. Who cares about background hidden files name anyway.