add sync strategy for native docker volume

[ignatiusreza]

to be used by default in linux environment, since docker built in support for mounting volume is good enough and we can use it without relying on rsync or unison..

part of #265

NOTE: I'm currently using this branch in my local.. give it some time to see if there're any issue, and I'll report back later..

[EugenMayer]

Hmm i really like the implementation, but i have some concerns i want to share.

Right now, you either chose a strategy explicitly or you get the default ( unison ). with your implementation we have to adjust a lot of docs to reflect that the default is platform specific.

Beside this effort, it makes really a lot of sense having platform specific defaults , since they have different OS capabilties.

That said, i guess technically, its the right move. But are you opting it for all those doc changes? ( wiki, examples and so on? )

[ignatiusreza]

yup, I'll update the examples once I give it some try locally to see if it's actually working.. regarding wiki, what's the timing for updates? I guess it should be updated only once new release are out, so that people who bound into them can actually use them.. and, any other places that need to be updated? noticed that you also have the boilerplate repo, need to be updated?

[EugenMayer]

I have an additional very interesting idea here, which could end up being one of the nicest addition since a long time. Your work here can be used for that too, makes it even more important.

Consider that we do the following on osx : native mount (osxfs) [host sync strategy/watcher] <-> sync container (unison) <-> named volume mount <-> app

This way we could remove unison/unox pain under osx, the pain of the native dependencies and also it's flaws while still maintaining the native speed in the app. What do you think?

#316

this implementation here could probably be shared, but i am not entirely sure we should share / it matches.

In this case, we need a dummy watcher ( native mount ) and sync_strategy will create a sync container + mount the volume directly - just what you did here.

It might be the same implementation, just in addition under a explicit new name. I jus think, native linux mount is exactly the same as native OSX mount, so why dublicate?

[ignatiusreza]

hmm.. give me some time to digest that first.. 😅 not that comfortable yet with how sync/watch works..

[ignatiusreza]

updated example with new section for default configuration

Consider that we do the following on osx : native mount (osxfs) [host sync strategy/watcher] <-> sync container (unison) <-> named volume mount <-> app

Regarding this.. I'm still not completely sure what to say to be honest... still trying to wrap my head around how the actual syncing/watching process works and how does it affect the performance.. though, IIUC.. the reason that docker-sync is needed, is because native mount on osx is slow.. so, in the graph above, won't doing native mount (osxfs) [host sync strategy/watcher] <-> sync container (unison) be slow? if it's still fast, why does mounting into sync container is okay, but mounting directly into app is not?

[EugenMayer]

@ignatiusreza lets continue the new strategy in a the issue and keep this one for linux only for now - lets see if we can merge the efforts here later

[ignatiusreza]

Cool! thanks for merging 👍