Bonito connection

[frankier]

This incorporates #211

Currently if you use WGLMakie/Bonito together with an interactive plot, Bonito will start a websocket server locally. It's nicer to have the endpoint managed by Oxygen so it's on the same port, can easily be put behind auth and so on.

Here's an example of how to use it

function __init__()
    @info "Setting up Bonito to use Oxygen websockets"
    @websocket "/bonito/{session_id}" Oxygen.bonito_websocket_handler
end

@get "/" function plot(req)
    WGLMakie.activate!()
    force_asset_server!(NoServer())
    force_connection!(Oxygen.OxygenWebSocketConnection(getexternalurl() * "/bonito/"))
    app = App() do session::Session
        # Plotting commands
    end
    app_html = sprint(io-> show(io, MIME"text/html"(), app))
end

This needs to be worked on a bit more. Better API, docs, tests, and also timeout management/session evication.

First I will open a ticket with Bonito to see which parts of the API are public in case it is possible to share more code.

Comments are welcome already though.

[frankier]

Another wishlist here is hooking Bonito into the same hot-reload logic as Oxygen.

[frankier]

Updated based on Bonito #244

[ndortega]

Hi @frankier,

Thanks for pushing for this feature, and I like the idea of introducing this as an extension. I've taken a peek at your other PR you've opened up on the Bonito.jl repo.

The only question/feedback I had was around these values used in the extention:

const open_connections = Dict{String, Session{OxygenWebSocketConnection}}()
const open_connections_lock = ReentrantLock()

How would this impact package developers who want to build a package on top of Oxygen? In general, we try to keep all stateful values inside the current context object to prevent values/configuration from clashing.

[frankier]

Good call! I guess the Context struct would need to have a extensions dictionary of type Dict(Symbol: Any} for extensions to put data into. This is the simplest solution, but if you have a more type-stable/JET-friendly idea, I'm open to suggestions.

When constructing a OxygenWebSocketConnection a user would then pass in the current context. I think however that probably a macro that does everything would be added in this PR (as well documenting the "manual API" where endpoints can be registered manually for those who want to add some custom behavior).

This all depends on a few bits and pieces though. Ideally we could first get #211 merged, and then if you agree I could make a PR adding the dictionary to the context object and add some docs for that.

[ndortega]

@frankier,

No worries about the type stability of the "extensions" dictionary. The feels like a good first step, once we get things working then we can try to address this later on with better dispatching logic.

At the very least the extension that is accessing this dictionary can add some getters and setters with the appropriate input/output types.

[frankier]

This seems to work okay now and seems feature complete. I've tested it manually, but adding some kind of smoke test would be nice.

What would you advise? I could of course easily call a couple of methods to test nothing throws an exception, but to actually test the connection properly a browser is needed. Bonito includes even a small framework for this: https://github.com/SimonDanisch/Bonito.jl/blob/master/test/ElectronTests.jl

This would be adding quite a bit of complexity to the tests, and again, it would at least be nice to reuse stuff from Bonito.jl, but this probably means asking @SimonDanisch to put ElectronTests.jl into a package, which he might not be ready to do. Otherwise I would probably vendor it for now.

What do you think? Might a low quality smoke test without a client be enough to make this mergable short term?

By the way, the other thing is that the API isn't absolutely amazing right now, including the requirement to import Bonito before Oxygen. This is why I put it as experimental in the docs, since some stuff will have to change when Requires.jl is dropped (it is unmaintained following the introduction of package extensions making it defacto deprecated).

[frankier]

Actually this isn't ready since it depends upon SimonDanisch/Bonito.jl#253 so first that needs to be merged, a Bonito release made and the Bonito compat updated or this functionality put behind a version check. (Let me know which you prefer.)