[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [flux-dev] follow up on sync mechanism collaboration
|
OK
Le 08/09/2014 20:28, Martin Lippert a écrit :
Hey Sun,
I created a bugzilla entry to track this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=443533
Lets move the discussion to that bug, ok?
Cheers,
-Martin
Hey Sun,
this is a very nice demo. Thanks for sharing the screencast. Looks awesome!
Contributing the Java FS sync part to Flux would be great, we should definitely start working on that.
I am not sure whether the Eclipse plugin should using that as well, since Eclipse is very much built around this resources abstraction that the Eclipse plugin is using at the moment, but we can evaluate that as well, of course.
I would also be interested in the changes you need to the Flux core and the messaging. Did you change any of the underlying protocols or mechanisms? Since the Flux protocol has still a number of wholes in it with regards to reliability, timestamps, missing stags, and collision detection, I would love to hear if you guys did anything in this area.
Cheers,
-Martin
We have written a SPI in Java to allow any file repository to implement what's needed to be a Flux repository. We have started 2 implementations:
- File System implementation, based on Java7 nio "watchers"
- of course a Eclipse Che VFS implementation
The FS implementation is pretty full feature
The Che VFS implementation is working one way for now: Che events converted to Flux messages and are broadcasted to all Flux participants. Che can also reply to Flux resource requests with file attachment when requested.
We have paused the development as we are pretty busy with other Eclipse Che urgent tasks at the moment.
He is a demo of Eclipse Che VFS implementation: https://drive.google.com/file/d/0B9vGYZYE8V2xaDI2TzVFdm9hUk0/edit?usp=sharing
And have you thought about joining the Flux project to work on this Flux-Che combination? Or would you prefer to do this as part of the Che project?
Yes. Actually, we think that all the generic parts should go to Flux:
- the Java FS sync SPI
- the Java7 FS implementation
It would be also a good idea to adapt the Flux Eclipse plugin to use it, WDYT ?
For the Eclipse Che VFS impl part, we are not sure.
At the moment, everything is hosted in Kevin Pollet's github, we thought we would wait the right time to move the project as everything is not ready yet:https://github.com/kevinpollet/flux-file-watcher
Though, you can have a look and give us some feedback :)
And have you guys also thought about the live edit sync mechanism and whether to use ShareJS for this or something else?
We think using Flux would be great, once we are done with the FS thing, we will probably give a try with Flux.
Cheers,
-Martin
Hi Martin,
Server side, Codenvy has a rest api to get the project resources and is using a custom VFS (with ACL) for storage. So I can see 2 options:
- run the node server next to the Codenvy main server, the Codenvy main server would work like a Flux client, it will also need to be able to provide resources and request for modified resources.
- re implement what we need in Codenvy main server as a Java module, don't use the nodejs server, if it would do nothing else than what i've listed before
I am not very familiar with the Codenvy structure and API, but I could imagine something like an add-on to Codenvy that acts like a repository (from the flux point of view). This component would need to connect to the Flux websocket messaging channel, listens to the file sync messages, and send out the corresponding file sync messages. This could be something like the MongoDB repo implementation that we have, but instead of using MongoDB to store the resources it uses the Codenvy storage.
Maybe this could be implemented using the Codenvy rest api. But I am not sure whether it would be possible for this component to be notified when a resource gets changed.
Yes, my team is starting to write a Codenvy repository for Flux, It will be written in Java. We will keep you inform on how it goes :)
As I didn't find any, i'll write some sequence diagram to explain how the file system sync work, what messages are sent and by who, will share it with you.
That would be great.
I also expect the file sync protocol to change in the future (as I said), but we can work on this.
Here is a first draft of the sequence diagram for the file system sync part http://sunix.github.io/flux-sequence-diagram/FluxFSSyncSD.svg, you can find the source here https://github.com/sunix/flux-sequence-diagram/blob/master/FluxFSSyncSD.pic
Any comments are welcome of course.
WDYT ?
See my comments above. Would be great to work on this with you guys.
Cheers,
-Martin
Cheers,
Sun
Le 02/07/2014 18:51, Martin Lippert a écrit :
Hey!
In the call last week between the Flux team and the Codenvy folks, we discussed a possible collaboration around the basic syncing mechanisms.
The call got recorded and is on YouTube: https://www.youtube.com/watch?v=TJWsawVkpjs, but it is 1h17m long, so be prepared… ;-)
As discussed I started to document a few general ideas about the architecture of the prototype on the wiki:
https://wiki.eclipse.org/Flux/Prototype
This page contains a few pointers into the code and explains the general ideas behind the mechanism of the prototype. There are a lot of open questions and things that need to be addressed in the future, but we can start a discussion around that here, if you like.
Looking forward to working on the more robust and bullet-proof synching mechanism.
Cheers,
-Martin
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
