Metadata System

[oeed]

This is a metadata based somewhat upon Lyqyd's previous proposal and previous input from others.

In simple terms, the system consists of a '.metadata' file stored in each folder which stores the metadata for each file in that folder as well as the folder's own metadata. The data is stored as Binary for fast and efficient storage.

I can see there being disagreements about this, so as with my suggestion in #42 I do not yet have an API written.

[oeed]

@demhydraz can you elaborate?

[viluon]

@oeed I think that @demhydraz would like to have custom keys, which you disallow:

It it completely prohibited to use any key not listed above or use an incorrect Value.

I would argue that for a solid metadata system, custom keys are a must. In @demhydraz's case, he would have to create another metadata format to function alongside this one to store additional information his OS needs for proper handling of executables, for example. Information about what rights different user groups hold for the file is crucial to the shell, but this metadata standard is infeasible for its storage.

Feel free to get some inspiration ([1], [2]) @oeed

[oeed]

Okay, I certainly understand where you are coming from. I was originally thinking that it would be a good idea but I can see a few issues.

The main issue is the inconsistency it will cause. Say, for example, @demhydraz starts using the key 'J' as a number value, say, the number of times it's been opened. If a folder then ends up @viluon's system which also uses the key 'J' as a number value, but instead for the colour depth, problems arise.

@viluon's system will try to open an image from the folder and use the number of times it has been opened, say, 7, as the colour depth. This has a reasonable chance of cause the file to become unreadable on that system.

It also requires a change to the format somewhat, as the keys are currently fixed you don't need a byte specifying what type it is as it already knows. That's not a major issue, but just something to consider.

[oeed]

Once again, elaborate?

[viluon]

Wow, extended attr. list is a good idea @demhydraz! I was thinking that you might add something like a custom key key, custom key type key and a custom value key (but the format probably doesn't support multiple entries of the same type right?). That would allow you to set up "virtual keys", which would be formed by custom-key = (string) "myKey", custom-value-type = (string) "number", custom-value = (number) 16. That means 3 new keys would be added, with which you could express any value you'd like to @oeed.

EDIT: Ehm, that might have confused you a little. Essentially you would add 3 new keys to the format, "custom key" (let's say K), "custom value type" (T is taken for MIME, so let's say it's lower case 't') and "custom value" (once again, V is taken, use 'v'). To add a new key, you would specify its name with K, its supposed type with t and its value with v. So for each new key you would add 3 new entries (that requires the keys in the file to be ordered, so new keys of the same name (K, t, v) can be reused for creating additional custom keys) which would describe the custom key.

Example: I would like to add a custom key "awesomeness" which is a scale from 1 to 10 describing how awesome the file is. That means 3 new entries: K = "awesomeness" t = "number" v = 9

Now I'd need another key, to describe how awesome the author of the file is. 3 more entries: K = "author's awesomeness" t = "number" v = 10

The keys in the file have to maintain their order, because otherwise you wouldn't know which value belongs to which key (in this case, the types can be swapped, because they're identical).

While usable, this is a rather crappy implementation of custom keys, mainly building atop what's already there. Extended attribute list as suggested by @demhydraz is a very good idea, but I would say the format itself should support custom keys in some way.

[oeed]

I really don't get this extended attribute list, can you explain @viluon?

[viluon]

@oeed extended attribute list would be a new key containing a file path where more metadata in a different format would be located. I believe this is the relevant Wikipedia page.

[oeed]

After a discussion on Gitter, it has been proposed that the keys are changed to 3 characters with support for custom keys and extended attribute list support be added to allow for greater flexibility.