Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDE (client) - workspace agent (server) event transport service #1824

Closed
5 tasks done
dkuleshov opened this issue Jul 18, 2016 · 1 comment
Closed
5 tasks done

IDE (client) - workspace agent (server) event transport service #1824

dkuleshov opened this issue Jul 18, 2016 · 1 comment
Assignees
Labels
kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed.
Milestone

Comments

@dkuleshov
Copy link

dkuleshov commented Jul 18, 2016

Overview

There is a need in a handy mechanics so we could transfer arbitrary information (events, data, etc.) from server side (i.e. workspace agent) to client (i.e. IDE web application) and backward.

Description

Most likely it would require to implement services both on client and server sides. The idea is to make a transparent service that should listen to events and transfer appropriate data through the transport bus (e.g. web sockets) using predefined transport protocol.

Here are a few examples of such events:

  • Client
    • file opened in an editor
    • file directory is expanded in a project explorer
    • project properties are modified
  • Server
    • file is modified
    • directory is removed
    • git operation is performed

It is also worth noting that services should not strictly define the way that data is transferred. The best way is to use some transport agnostic protocol to be able to extend or change the service. So we should consider means for convenient change of transport bus (e.g. from web sockets to REST).

As a transport protocol most suitable seems to be Json RPC protocol or something similar. It is Json based so it would make it easy to implement and to use.

Technical aspects

  • Bidirectional web socket conversation
    • Client-server data transfer protocol that are applicable in our application are asymmetric in a way that server cannot start conversation on demand but only a client
    • Web sockets are also asymmetric but there are ways how to overcome this limitation by using workarounds that only web socket protocol provides.
    • Bidirectional behavior requires us to implement both sides for requests and responses processing. Those implementations differs because of the nature of client and server.
  • Several agents support
    • There are several use cases when there can be a few IDE's opened and connected to a single server (workspace agent)
      • Several tabs in a single browser
      • Several browsers
      • Several users of a single workspace
    • That requires specific management approach for data transfer (via web socket).
    • This will require both server side and client side modifications
    • This will not require any work related to UI
  • High level data transfer protocol (Json RPC)
    • Transport agnosticism - in order to be able to use REST and web socket depending on our needs
    • Conformance to the specification
  • Effective client side and server side event handling
    • We have a good client side event handling but it does not support new data transfer approach
    • We have VFS event handling system implemented so we just need a proper event detector implementation

Technical tasks

User stories

@dkuleshov dkuleshov added kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. sprint/next team/ide labels Jul 18, 2016
@dkuleshov dkuleshov added this to the 4.6.0 milestone Jul 18, 2016
@dkuleshov dkuleshov self-assigned this Jul 18, 2016
@vparfonov vparfonov removed this from the 4.6.0 milestone Jul 18, 2016
@dkuleshov
Copy link
Author

dkuleshov commented Jul 22, 2016

After some initial work and analysis I believe the ETA of this epic should be about 3 weeks:

  • Technical scenarios - 2 weeks
  • End user scenarios - 1 week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed.
Projects
None yet
Development

No branches or pull requests

2 participants