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