Got the server and console/logger proxies implemented, starting the telemetry proxy and then I'll have all of the "shared services" and a working basic RPC server implementation for both servers, since most of it is shared code.
I might have gone a bit overboard with the console options... we get to configure/customize background and foreground colors per log level for each part of a log entry (id, timestamp, log level, message, verbose message), and for the GUI client there's knobs for font family, size, and weight
Ok so we're getting a ServerConsoleLogger, that doesn't yet interact with NLog, but the idea is to have all server-side logging go through it, so the trace-level server logs can be sent to the client if it's configured for it, per LSP.
Also IServerNotificationCommand and IServerRequestCommand and their respective delegate implementation
every client notification is handled server-side by invoking an IServerNotificationCommand; requests are handled by a IServerRequestCommand command that returns the response result.
Pulling every server (and client) action into a base command will make it very easy have pretty good telemetry data.
(without needing to sprinkle telemetry logs all over the place)
The console stuff mostly isn't specified in LSP, so I added [RubberduckSP("name")] and pulled a common base class with [LspCompliant("name", minVersion = "3.17")], so it'll be easy to get all the RPC paths with reflection when I wire them up.
One interesting implementation detail, is that the proxies only live until a request returns a response (or until a notification is handled); so the entire state of everything is (/could/should be) immutable all the way through.
Oh and everything will have xmldoc (I've never so thoroughly documented my code 😅)
The versioning will be useful when LSP evolves and we want to keep up and we have older 3.x releases out there.
the .NET core seems to be more friendly toward this kind of setup and that would totally eliminate the need to register COM and stuff from the .NET side while having control over the runtime.
@MathieuGuindon sounds like you put in a lot of thought. One question, though - does that implies that we're going to be constantly creating and destroying proxies?
@MathieuGuindon That could just be a "choose where to sync to" dialogue that shows the first time a new project is opened. Frankly I'd rather have no setting at all - do we really need to configure export location, tB doesn't let you. Wait until there is demand for it then decide. But I'm fine with a ./Export folder relative to the host file.
No settings to sync then
@MathieuGuindon Middle- ground - an explicit "non-default-settings" file rather than an "all-settings" file to commit in your git repo. Like .rdcustomsettings or .rdoverrides rather than.rdsettings. It's a small thing I guess
@Greedo I think I'd go with ./VBProjectName (could work nicely with multiple .xlsm in same folder, just name each VBA project!), but yeah nobody will want the exported code too far from its host document.
@Greedo I think I have an idea how to make that work: if there's a non-default config (.xml or .json? hm hey why not both!) then we skip the db load and use the "factory defaults", then we load and apply the non-default config diff. If there's no non-default config file to load, we load the local settings from the SQLite database.
I guess the search location(s?) for non-default configs could be one such application-scoped setting: if these kinds of settings came from files, they'd live in the RD install folder.
in the db, they're application-scoped
wait no, non-default configs would be for project-scoped settings, yeah?
hmm, could really be either
anyway it's Sunday, means it's clean-up time
I'm moving the parts of lsp I'm stealing for rsp messages into a "SharedServices" namespace, so that there's no using Rubberduck.InternalApi.RPC.LSP.* anywhere in the Rubberduck.Server.LocalDb stuff.
@MathieuGuindon (Use TOML if you can toml.io/en, it's got first class support in python standard library so it's mature and tested, it is both human and machine readable. Good for config.)
@MathieuGuindon for project settings I'm confused, what does the local dB define different to factory defaults + custom overrides? I was imagining that any override file (missing == empty) would be enough. Is this just a cache in the local dB for speed? Is that not premature optimisation?
I.e if there is no file, rather than load local settings wouldn't you just lead factory defaults and apply diff= 0
Oh no I see. Local settings override factory defaults in new projects on that machine. But if a config file is provided then we must use factory defaults as the base to diff from, not local default.
In that case how about ”if no overrides config file is present, load local settings from dB and write any non-default settings to a new override file for that project" (on first code sync/export, to avoid creating files when user isn't interested in source control and just wants a self contained .xlsm)
Then next time the project is loaded the override settings can't change while you were away. Otherwise a user could specify bin default settings on one day, make a project A, go work in project B, change local preferences again and then come back to project A to find their new settings have broken it somehow
hm, RD3+ updates could be released in patches that only install a new build version for Rubberduck.Server.LSP, or whichever not-the-addin-assembly assemblies.
we'd have an installer for the add-in client, and then another for the server bits; the add-in client installer installs the servers, but the servers can be updated independently.
you could leave Excel open, bring up the server client, click the "shutdown" button, update the server, restart it, and go on with your day
damn, no-interruption updates are possible!
you just keep coding with the disconnected client opened, and then update completes and server starts and client reconnects and poof syntax highlighting is back and you've just updated Rubberduck
VBA Rubberducking
VBA Rubberducking