Metadata and preview (persisted/replicated) storages

[kirillt]

Written for Link-to-Web resources, but might be valid for other kinds as well.

Right now, we are storing metadata and preview in the same archive with the URL. Any change in metadata like title or description will change the link's id and invalidate tags for new version. We can create dedicated metadata storage, like .ark/meta. This way it would be also easier to work with the same resource on several devices since we could modify tags on device A and modify metadata on device B, but both modification would point on the same id.

Previews also should be kept separately, because the same URL can get different preview just because of changes at remote site. If preview changes, we would just update picture in .ark/previews without need to update ids.

[kirillt]

We need also "our own" filenames, which we would put into .ark/meta. Such resource names would be de-coupled from locators (filenames and paths). Since we use content addressing, the only locator we accept is ResourceId (and root path, but this is temporary measure).

E.g. we copy resources

(name=A, id=1),
(name=B, id=2),
(name=C, id=3)

from root X into root Y.

Root Y contains resources

(name=A, id=4),
(name=D, id=5),
(name=E, id=2)

Currently existing file browsers would solve this case like this:

File A exists in folder Y, do you want to overwrite? Y/N

What we have after the operation:

(name=A, id=1 or id=4),
(name=B, id=2),
(name=C, id=3),
(name=D, id=5),
(name=E, id=2)

Here we have: 1) less resources than we wanted: only 4 instead of 5 (we can't have both id=1 and id=4 under the same filename) 2) duplicates: two files with the same content but different locators

Resource browsers based on content-addressing should solve this case this way:

(No questions asked, user clearly specified which resource they want in destination)

What we have after the operation:

(name=A, id=1),
(name=[B,E], id=2),
(name=C, id=3)
(name=A, id=4),
(name=D, id=5)

I.e. we have all 5 unique resources, no questions asked. The only slight inconvenience we have is that one resource got two names. But we don't present this resource like different files, user can always choose name they like more or leave it as-is.

[kirillt]

Previews storage is implemented now, we need also to create metadata storage.