# Project Roadmap

[retailcoder]

As the early skeleton-building stages begin to conclude, it's time to start planning the next phase and break it down into issues/stories any contributor could pick up and deliver.

Where are we now?

Before going anywhere, it's a good idea to take a moment to assess where we're at first. The project was started from scratch (new solutions new projects) in Microsoft Visual Studio 2022, targeting Framework 4.8 and successfully loading as a VBIDE add-in in the current/latest version of Office 365 for Windows desktop.

No attention was given to deployment; there's no meta-project, no CI integration; running the add-in with a debugger requires running VS as administrator. No inspections, no refactorings, no navigation tooling, no unit testing, ... it'll take a while to go through everything that's not there yet, so instead let's take a look at the solution architecture, and go from there.

Overview

As expected, LSP changes everything. The language server will be Rubberduck's brains, and the add-in will be just a host for our editor. The rather harsh separation between the client and its LSP server (each add-in client instance spawns its own LSP server process), forces complete decoupling, severing any ties between the parser and the VBE - types like Selection and QualifiedMemberName live under the Rubberduck.VBEditor assembly in 2.x, but with LSP we cannot have that project reference, so we'll find them under the Rubberduck.InternalApi library project in 3.x.

UI is also more clearly separated now too, and the UI.Xaml library contains only (but all) xaml UI components (which could conceivably be shared between the add-in and other client processes). Similarly the UI.WinForms library contains all the (few) Windows Forms UI components, leaving the Rubberduck.UI library with the UI-layer code.

The Rubberduck.Model library contains the declarations model and everything else that pretty much all the projects need to do their respective thing. Speaking of declarations... Out of necessity (we need them serializable), they're no longer exposing Antlr types, so this may spell trouble for some inspections and several other features that relied on these parse tree bits.

The parser is present and handles/reports syntax errors - as seen with the client-sided proof-of-concept code, but there is no semantic layer yet... we need to think about how we want to do this with LSP in mind: implementing LSP was always going to have some serious implications with that particular piece of Rubberduck. That said I'm pretty sure we will end up reusing 99+% of the 2.x resolver code, just organized differently.

Memory & Storage

The LSP server being its own process means "Holy RAM, Batman!" gets closed as resolved forever... but then, with each client instance spawning a dedicated LSP server we would be caching the same data over and over every time. Instead, we introduce another server layer and run a SQLite database in a RPC server process that all LSP clients will be connecting to, and that solves many problems already (concurrent, cross-process writes to the same .db file? Windows doesn't think so!), while opening a bunch of fun new possibilities for configuration and other things that need to be persisted.

Rubberduck3 basically moves the storage out of in-process RAM onto disk, and the data access moves out-of-process into LSP. What we do with the DeclarationFinder in 2.x, we'll be doing with data services / queries.

RPC

The add-in client communicates with the LSP server via LSP-compliant messages sent using the JSON-RPC protocol on a named pipe transport. As a client, the LSP server communicates with the LocalDb server in a similar way, but through an adhoc protocol that sometimes borrows from LSP.

At this stage the shared RPC platform is working, but work is barely starting on the LocalDb server implementation.

---

Where are we going?

The objective is to make Rubberduck what we always wanted it to be, but there's a lot of work ahead and it needs to be organized and planned.

Backlog

The Rubberduck 3.0 executables:

• LocalDb server
• LocalDb client console GUI app
• LSP server
• LSP client library
• LSP client console GUI app
• VBIDE add-in LSP client
• Telemetry server
• Telemetry client console GUI app
• Installer

In Jira terms, each of them roughly corresponds to an "epic" that could easily be broken down into smaller objectives and deliverables.

For the LocalDb server, scripting the SQLite schema and implementing the CRUD against it would be priority one; defining the RPC interface and exactly how the LSP server is going to request data and the shape of the data it's getting back, would be a close second. Once that's done, work on the actual LSP server implementation can start.

Meanwhile LSP being a protocol, what the communications looks like between the LSP server and its clients is already known, so work could begin on the Rubberduck.Client library, which should house all the RPC client abstractions that could be shareable between the LSP server (as a client to the LocalDb server), the add-in client, and the server console GUI apps.

Pure UI work could happen at any point along the way, for any toolwindow or xaml controls, from a custom object browser to IntelliSense tooltips to custom theming capabilities and styling. With a model defined, the whole add-in client could be implemented, independently of how far along the LSP server is.

Deployment and installer work could probably begin early too. Actually if we are to retarget the server parts to .net 6 it's probably better to do it early on.

What are your thoughts? What do you want to work on and contribute? Let's discuss here, and then use the projects GitHub feature to split up epics into issues that we can milestone.

[MDoerner]

Thanks for putting this together. Two remarks immediately came to mind.

1. I disagree that probably more than 99% of the parser and resolver are reusable. Here, the issue is not the LSP approach but the fact that we now use our own editor window. Currently, we rely on the VBE's pretty printing to disambiguate grammar structures like index expressions and call statements on arguments enclosed in parentheses. Without the VBE helpfully inserting/removing whitespace there, this cannot be distinguished on the parser level. So, it needs to move from the parser to the resolver.

2. We need to think about how refactorings should work, especially those with a gui. The logic probably needs to go on the langue server side since that is where the necessary information is available. I guess, we then have to send the model back and forth to deal with the gui part. Finally, we need to send over some instructions, probably to some generic component in the client, what to edit and what modules to add/rename/delete. I think for most of our refactorings, this should not be much of a problem, because the model is just data. However, at least the new extract method refactoring has implementation logic in there.

[retailcoder]

1. You're right, of course 😉
2. Correct again; refactorings (as well as quickfixes) are mostly covered in LSP under code actions (rename is its own workflow though, with a "prepare" request to validate the new name). Code actions carry an object (the model data, must be json-serializable) between their respective resolve and execute requests, specifically for this.

[mh166]

Dear @retailcoder,

I hope this message finds you well! First off, I just want to express my appreciation for all the incredible work you’ve done on Rubberduck - both on the current stable as well as on this rewrite. It’s such a massive undertaking, and it’s clear how much thought, care, and effort you’ve poured into it. Your contributions have been invaluable to so many of us who follow and use the project. Thank you for everything you’ve done so far! ❤️

I noticed that the project has been quiet for a little while (which is completely understandable—life happens, and all of this is done voluntarily in your free time). I wanted to reach out to kindly inquire if there might be plans for further development in the future. Of course, I fully understand if priorities and focus have shifted or if the project is on pause indefinitely. No pressure at all—this is just a note of encouragement to let you know that I (and likely many others) am still looking forward to any updates if and when they happen.

Either way, please know your work has been deeply appreciated, and I hope everything is going well for you. Wishing you all the best in whatever you’re working on these days!

Warm regards,
mh166

PS: While I’m mainly addressing you in this message, the same appreciation goes to everyone who’s part of the team or has contributed in any form along the way. All of those contributions make Rubberduck the amazing project it is today!

[retailcoder]

Hi, thanks for the kind words! I don't want to announce anything because I don't want to be done with RD or RD3 (and the website/hosting renewals are coming up), but basically what happened is that I got sidetracked with the editor/client part, and while that's what users would be interacting with (it does matter, quite a lot), it shouldn't have taken a higher priority than advancing on the language server side of things, and with the twinBASIC beta making significant strides towards VBA integration I'm thinking about the future of RD and VBA, and not sure where Rubberduck stands (or should stand) in the bigger picture.

Then I was sidetracked with fixing the website, and let it collect dust way too long and starting to feel some heat on that front; I need to get back to this like, yesterday. Since 2021 I'm not half as available as I used to be for a number of reasons, and now life has literally happened, as I'm home with a newborn, and while it's great news for me and my family, I realize it's looking a bit bleak for Rubberduck right now.

So what's likely to happen, is as follows:

• I'll finish the website and migrate hosting over to an Azure VM (the test site and backend is already running on one).
• Not sure when, but RD 2.x will have another release, minimally with what's already in next (although there are a number of not-yet implemented enhancements I'd like to also include in that release).
• RD 3.0 will be re-scoped a bit; a totally custom editor /LSP client is way too ambitious and ultimately unrealistic, and would be spreading dev resources way too thin for comfort, so we'll use an existing one instead, most likely the same as twinBASIC.
• RD 3.0 LSP implementation will eventually resume, but I don't have a timeline and don't want to commit to one at this point in time. Happy to help anyone willing to jump into it though.

Project is not dead, just kind of temporarily sleeping 😊