KeeShare should allow for "temporary" import

[droidmonkey]

Summary

KeeShare currently imports the shared database into the main database. The structure and entry information is saved with the database. This is advantageous for certain scenarios such as offline use. Having the ability to "hot load" a KeeShare folder that does not get saved with the database would be very useful in some circumstances (large attachments).

Desired Behavior

Add an option to allow a KeeShare folder to be "hot loaded" and the contents not saved with the main database.

Possible Solution

Create a special group class for KeeShare groups that can store information about their behavior and modify how save/load works.

Context

Just a thought I had.

[ckieschnick]

This is an interesting concept. I'm just going to dump some of my thoughts about the implementation and problems to encourage some discussion.

To enable this scenario, we would need to keep track of the imported entries (so we have to create some sort of volatile entries by using a flag of some kind) to prevent them from influencing the saved state of the database.

This means that some of the core components need changes:

• the merger needs to be adapted to handle this special case given information that the data changed but not the persistence.
• the serializer which needs to ignore the volatile entries.
• the scenario does have some implications on the ui too. It would be good to have some kind of "open" and "close" for those hot-loaded shares.

Furthermore there are a number of edge cases which need to be defined:

• is there need for custom data (especially database wide) which needs to be merged but is volatile?
• what happens if the user references a volatile entry. When the share disappears, the reference is invalid (at least for now).
• what happens if the user moves a volatile entry out of its share group (simple move, move to recylce bin or even real delete) or changes the entry? Is this entry removed from the share, or do we need to have some kind of event log about those actions to replay them on reload?

Just a personal thought - currently a lot of things are marked with KeeShare because some part of KeeShare has code which assists the proposed feature. I would suggest to separate those features as separate plugins (maybe even extracting some "common sharing core" (similar to the crypto code) which can be used from those plugins). This eases the discussion since we can clearly separate the usage scenarios.

[droidmonkey]

I'm going to leave this to the side for now, its an interesting thought experiment, but may not be ready for prime time in the current code base.

[dsonck92]

This sounds very very close to my original idea written in #2355 and I would love to see this extension. While the current merging of keeshare is fine I can also see the possible problem of having a large keeshare database merge into the parent database.

I would say that changing it from "temporary" to "external" would better explain the feature. Or perhaps mount points as I called them earlier. In my vision, they would be:

• Loading all entries and directories as is in the referenced file
• Modification to these entries can be written out to the referenced file if desired (but readonly enforced mode would be useful to have)
• Completely isolated from the main database, that is, moving something out of them is deleting much like dragging entries between databases

Looking at the points for corner cases, this would be my input:

• I see no database settings that would benefit from sharing, as most refer to the specific file
• In my case, the volatile entries would be assumed to exist, and referencing a keeshare database which doesn't exist at the time of opening is an error.
  This does not handle the case where something is referenced and upon next opening, the share does not have its value anymore. A possible solution could be to keep the actual last value inside the item which references, but it prefers the reference value if it exists.
• Depending on whether it is marked readonly, all changes would be propagated to the share relative to its group. If it moves outside, it's removed. In essence this makes the shares some kind of barrier and act like an mounted unix filesystem.

[droidmonkey]

This won't be implemented.