Updated Client server discovery lifecycle (markdown)

Josh Suereth 2013-10-16 10:10:23 -07:00
parent b3e4fbf1d7
commit dce4f60d88
1 changed files with 8 additions and 3 deletions

@ -86,6 +86,12 @@ Here's a more concrete proposal of how launching a server would work. However,
restoring any state they need on the server upon reconnect.
4. The sbt server needs to outlive the original client that requested it, and only shut down when it has
no more clients.
5. The lock file location uniquely identifies the type of server launched. Only one server per lock-file.
The launcher makes no assumptions about semantic meaning across launch configurations. Only the
lock file.
6. The protocol exposed by any server MUST be HTTP. While the URI returned may allow users to negotiate,
making a HEAD request against the returned URI is guaranteed to succeed and becomes the mechanism of
pinging a server for "up".
So, first We create a new interface for the sbt launcher, called `xsbt.ServerMain`:
@ -95,7 +101,6 @@ package xsbti;
public interface ServerMain {
public java.net.URI start(AppConfiguration configuration);
public boolean isAlive(java.net.URI active);
}
```
@ -128,7 +133,7 @@ This is done via a new configuration similar to AppConfiguration, only with an a
components: xsbti,extra
cross-versioned: false
resources: ${sbt.extraClasspath-}
lock: .active.properties
lock: ${cwd}/.sbtserver/active.properties
[repositories]
local
@ -160,7 +165,7 @@ This will return the URI of an active launched server. It will use the below ps
```scala
def serviceLocator(config: ServerConfiguration, launcher: Launcher): URI = {
def isReachable(info: URI): Boolean =
launcher.server(config).isAlive(info)
canMakeHeadRequest(info)
withLockFile(config.lockFile) {
readServerInfo(config.lockFile).filter(isReachable) match {