search

sbt / sbt-remote-control

Create and manage sbt process using unicorns and forks
Other
74 stars 14 forks source link

Compilable with ScalaJS? #125

Open nightscape opened 10 years ago

nightscape commented 10 years ago

Hi all,

I'm wondering if there are plans to compile the client part with ScalaJS. This way, many of the Javascript-based (collaborative) code editors could get information about compilation and test errors from the SBT server. Also, would it be possible to plug a code completion plugin into the client-server architecture?

Best Martin

jsuereth commented 10 years ago

On Thu, May 8, 2014 at 11:38 AM, Martin Mauch notifications@github.comwrote:

Hi all,

I'm wondering if there are plans to compile the client part with ScalaJS. This way, many of the Javascript-based (collaborative) code editors could get information about compilation and test errors from the SBT server. Also, would it be possible to plug a code completion plugin into the client-server architecture?

Regarding #1 - The raw API is just JSON, although we don't have an HTTP/JS client yet

Regarding #2 - Yes code-completion plugin should be possible, although all the details aren't fully worked out. We'll have to break some SBT binary compatibility in the compiler-interfaces to fully expose the REPL so the full API is delayed until then, but some experiments so far: https://github.com/sbt/sbt-remote-control/tree/wip/jsuereth-server-repl-support

nightscape commented 10 years ago

I'm just playing around with this a little. I guess for the connection side, something like WebSockets would be best suited, as both client and server can send messages at any time, right? I had a look at Socko and spray-websocket but both assume an Akka system in the background. From what I've seen, client handling is done via threads, right? Maybe something like Backchat's Hookup might be suitable?

jsuereth commented 10 years ago

For now. The protocol itself is standardizing but the current socket implementation is designed such that we can rework/redesign when ready.

I think having a websocket option (and pure socket) will be a feature we add after we iron out more non-protocol decisions (things like semantics and API) On May 18, 2014 5:13 PM, "Martin Mauch" notifications@github.com wrote:

I'm just playing around with this a little. I guess for the connection side, something like WebSockets would be best suited, as both client and server can send messages at any time, right? I had a look at Socko http://sockoweb.org/features.html and spray-websocket https://github.com/wandoulabs/spray-websocket but both assume an Akka system in the background. From what I've seen, client handling is done via threadshttps://github.com/sbt/sbt-remote-control/blob/master/server/src/main/scala/com/typesafe/sbtrc/server/SbtClientHandler.scala#L31, right? Maybe something like Backchat's Hookuphttp://backchatio.github.io/hookup/might be suitable?

— Reply to this email directly or view it on GitHubhttps://github.com/sbt/sbt-remote-control/issues/125#issuecomment-43451800 .

nightscape commented 10 years ago

Ok, so I'll put my efforts on hold for now. Looking forward to Scala becoming one of the best languages in terms of editor support :)