Re: [flux-dev] Flux Integration into Codenvy Eclipse plug-in

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey!

> OK Let's do it Monday 23rd, all the Codenvy Eclipse plugin team is in CEST and a meeting in the afternoon/evening would be perfect.
> I suggest 4:30PM CEST (7:30AM PST), would that be ok ?

Sounds good to me. I would suggest to use Google Hangout (for which I would need your Google IDs).

Cheers,
-Martin




> 
> Cheers,
> 
> Sun.
> 
> Le 13/06/2014 18:23, Martin Lippert a écrit :
>> Hey Sun,
>> 
>> great to hear from you. A 1 hour video call sounds like the best option to introduce the Flux structure and to discuss possible ways to collaborate.
>> I am in CEST, so something in my evening time would be preferred (which would be in the morning of Pacific Time). Would that work for you? My preferred day would be Monday 23rd, but Wed 18th would work we well.
>> 
>> What do you think?
>> 
>> Cheers,
>> -Martin
>> 
>> 
>> 
>> Am 12.06.2014 um 17:01 schrieb TAN Sun Seng David <sun.tan@xxxxxxxxx>:
>> 
>>> Hi Martin,
>>> 
>>> I'm Sun TAN, team leader at Serli of some plugins we are building for Codenvy. We are very happy to start working with you and maybe contribute to Eclipse Flux and help you making Flux a mature and nice framework.
>>> 
>>> The Flux synchronization mechanism looks promising but we have no idea how well it will fit with our requirements.
>>> Maybe you can tell us how Flux can fit with it:
>>> 
>>> Codenvy has workspaces and projects in their servers. It's mainly VFS that we can access through the Codenvy REST API
>>> The Codenvy Eclipse Plugin goal is to checkout projects from Codenvy locally so users can use their favorite IDE with projects hosted by Codenvy.
>>> Also, one of the main thing is we'd like to make offline work possible (which is not the case with the Web based IDE at the moment) where users could work in a plane or on a boat :)
>>> 
>>> At the moment we are thinking making a sync that would look like the Git one, but without the versioning stuff.
>>> From Eclipse, user would perform a sync request and the Codenvy Eclipse Plugin will show Codenvy and local file differences and conflicts and suggest to upload/download/merge files. The UI would be based on the Eclipse Team provider.
>>> 
>>> Could you tell us how/if this workflow would differ with Eclipse Flux ?
>>> 
>>> Also would it be possible to have and 30mins/1 hour audio/video call with you so you could introduce Flux and so we can have a better idea on how Flux works and when we can plan to ship something :)
>>> 
>>> OK for the mailing list, adding it to this mail (and hope it works),
>>> 
>>> I'm also adding Stéphane Daviet, one of the Codenvy Eclipse plugin developer to this email,
>>> 
>>> Cheers,
>>> 
>>> Sun.
>>> 
>>> Le 10/06/2014 18:33, Martin Lippert a écrit :
>>>> Hey Tyler, Hey Kevin,
>>>> 
>>>> thanks a lot for the introduction. I am very happy to hear from you about this.
>>>> 
>>>>> May I introduce you to Kevin Pollet, with Serli.   They are a Codenvy partner, and have been actively building an Eclipse plug-in to interact with Codenvy services.
>>>>> It is getting quite mature.
>>>>> 
>>>>> In their next sprint, they will begin doing work on a synchronization protocol to keep changes made in an Eclipse client in sync with changes made in a remote workspace.  I have asked them to look at Flux as a possible solution to this.
>>>>> 
>>>>> I wanted to put you guys in touch in case there were any questions and / or collaboration opptys.
>>>> I added John Arthorne to this, since he is the other project lead on Flux @ Eclipse.
>>>> 
>>>> The synching mechanism in Flux is at a prototype level only at the moment, so maybe nothing you could use right away. However, it is implemented from an interesting (and maybe promising) viewpoint of sending messages around in contrast to using a RESTful API or something like that.
>>>> 
>>>> If you would like to implement something like that for Codenvy, it would be great if we could come up with something that could maybe serve as a base for a future stable versions of Flux. Maybe we can collaborate on this? That would be awesome
>>>> 
>>>> The syncing mechanism in Flux is designed to work on top of asynchronous messaging only and in a distributed environment without a dedicated master repository. So nodes are synching with each other via messages. This opens up a whole lot of possibilities, but might make the syncing protocol more complex. What do you think? Did you take a look at the Flux prototype implementation?
>>>> 
>>>> In addition to the pure file syncing, Flux is also doing real-time syncing while typing, which provides an important backbone mechanism for all kinds of development services. I am not sure, but it could be worth to implement a unified version of this syncing that is able to do both.
>>>> 
>>>> I also briefly looked at differential synchronization instead of operational transforms to do this and that opens up a whole lot of additional possibilities as well, but I haven’t implemented anything yet.
>>>> 
>>>> Maybe we can continue the discussion about that on the flux-dev@xxxxxxxxxxx mailing list, so that people around Flux are aware of this thread? That would be great.
>>>> 
>>>> Looking forward to collaborating on this!!!
>>>> 
>>>> Cheers,
>>>> -Martin
>>>> 
>>>> 
>