bloop
                                
                                 bloop copied to clipboard
                                
                                    bloop copied to clipboard
                            
                            
                            
                        Can bloop server support socket file in addition to port number?
It is better to have socket file as server entry point. Especially in a multi-user server, it makes users independent work locally.
Are you asking for support of something like UNIX Domain Sockets? And for which clients? The CLI or BSP clients such as Metals? Bloop supports Unix Domain sockets in BSP clients and CLI clients, though in the latter case it is not straightforward to set it up.
Thanks, would please share some documents or bloop repo code snippet? By Unix domain socket, I mean a file path. In this way, the users can be more isolated to each other.
The using senario includes BSP or Bloop clients or Bloop.CLI. Each user can start a server that totally private, that others in the same server cannot access through a public PORT.
Here is the requirement reason: https://github.com/sifive/api-scala-sifive/issues/32, https://github.com/sifive/api-scala-sifive/issues/14.
Many thanks!
@davidmlw Thanks for elaborating on your use case.
You can use Unix Domain Sockets or named pipes (which are essentially just socket files) with Bloop via bloop bsp --help will tell you how to connect to it. Our launcher (used by tools to start bloop in a machine and connect to it as a client) also has support for it, see the implementation. But this constrains the use of Bloop only to BSP-based clients. The CLI is not a BSP client and our nailgun integration does not currently support Unix Domain Sockets or named pipes directly.
You could, in theory, run the server with coursier launch ch.epfl.scala:bloop-frontend_2.12:1.4.0-RC1-165-906110dc -m com.martiansoftware.nailgun.NGServer -- local:/path/to/comm.socket and use the soon-to-be-deprecated python-based bloop CLI to connect to it with bloop --nailgun-server local:/path/to/comm.socket bloop.Cli $YOUR_COMMAND where $YOUR_COMMAND can be any valid bloop command such as compile, test or run.
However, I haven't used that myself and I would recommend not using it because the python bloop script will be gone with the next release.
I agree we should support these use cases better. To do that, we would need two things:
- Make bloopgun, which compiles to GraalVM Native, use native Unix Domain Socket and named pipes API. I believe @alexarchambault did this via the GraalVM bindings so we might want to reuse that code. Alex, any idea where that code is living now? I tried to look for it without luck.
- Change our nailgun server bloop.Serverto support local paths to socket files or named pipes, asNGServerdoes above.
If this is something you're interested in implementing, let me know. I'm happy to help out in any way. I would like to see the bloop CLI supporting socket files by default.
/cc @jackkoenig with whom I've had chats about this or a very similar issue in the past
Your reply resolves my confusion. I was wondering how bsp clients, like metals, start bloop server. I dont have capabilities to do such kind of development now.
I think the root requirement is how to support multi-user. If the current server mode can support multi-user without security problem, it is a better solution. So a server may need start only one service and provide services to every users.
@davidmlw Metals uses the Bloop launcher to start Bloop itself. Not sure if we can just add another parameter there to use socket files or we still need to have the changes mentioned by @jvican
In both cases we will need to have something changed inside Metals for sure.
This would be interesting in the context of developments I work on right now. In particular, using a named socket to connect to the bloop CLI would make it easier to use bloop from docker (where it can be a hindrance to set up networking just for bloop).
This shouldn't require a lot of work. I think the following should do:
- in snailgun, add a Clientaccepting aSocketrather than just an host / port
- use ipcsocket rather than the custom named socket implementation here - I confirm the JNI implementations in ipcsocket work fine from GraalVM native images (at least on macOS)
- default to a named socket in bloopgun (in a fixed directory under the user home, putting the PID of the server process in the file name, say)