Re: [flux-dev] Status update

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey!

Another thing to keep in mind and think about is the mechanism that detects changes among synced flux clients.

How do you detect that an incoming file change isn’t overriding a local change to the same file? For the prototype I used a timestamp, which was a simple and stupid choice. It basically said that the highest timestamp wins. For a real implementation, you need a bit in place to at least detect this situation and resolve that somehow.

I think you need something like a global, random ID for each file state that is kept when receiving a file. Whenever you send out a change, you would tell the receiver that the previous version is of that UUID. If the receiver has the file in that state, he can safely accept the changed file. If not, you might need to figure out history of changes, etc.

So a robust implementation for that would be a great addition to the file sync mechanism in Flux.

Cheers,
-Martin





> Am 01.07.2016 um 09:33 schrieb Sun Tan <sun.tan@xxxxxxxxx>:
> 
> Hi Fjodor,
> Sorry for late reply. I haven't gone through Flux source code recently. But as far as i remember, for resources synchronization it is basically using Eclipse project resource api to interact with project files. It is already an abstraction and i'm pretty sure there is code sources that are very similar to the file watcher stuff. The good think with Eclipse project resource api is that you already have a project abstraction. Years ago before java nio it was hard to "watch" for file modifications and Eclipse resource api was good alternative (assuming everything is changed in Eclipse).
> So i think you should:
> - merge the logic of file system sync: Eclipse flux plugin implementation and Flux file watcher implementation should use the same code to build messages and send to flux and receive messages
> - this merged code should use a api to look at project file changes and update files
> - You will need to refactor eclipse flux plugin to build an adapter that would use eclipse project resource API
> - Command line file watcher would use packaged javanio impementation + the merged code
> - Eclipse flux plugin should use your adapter + the merged code
> 
> I not sure if all this is easy or even possible, but it is worth it to have a look and make the whole code more maintainable.
> 
> Cheers,
> Sun.
> 
> Le ven. 24 juin 2016 à 14:12, Vershinin Fjodor <fjodor@xxxxxxxxxxxxx> a écrit :
> Hi, Sun!
> 
> As you can see, flux-file-watcher-core works like a SPI: we had in the original repository
> - an implementation for classic file system (using java nio)
> - an implementation for Old Eclipse Che (named Codenvy here)
>  
> I think it makes sense to refactor the Eclipse fs sync part and have an implementation of the spi for eclipse "fs" ( project resource api). WDYT ?
> Could you be more specific about those refactoring ideas? I am very interested, because currently I am thinking how to proceed.
> 
> Thanks,
> Fjodor
> _______________________________________________
> flux-dev mailing list
> flux-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/flux-dev
> -- 
> 
> -- 
> 
> Sun Seng David TAN
> Senior Java Developer
> Eclipse Che commiter
> 
> 
> Mobile : +33 21 02 41 73
> Email : sun.tan@xxxxxxxxx
> Site Web : www.serli.com 
> 
> Suivez-nous sur Twitter : @SerliFr @sunsengdavidtan
> et Facebook : SerliFr  
> _______________________________________________
> flux-dev mailing list
> flux-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/flux-dev