GSoC 2026: Interest in 'Prototype New Dart IntelliJ Plugin using LSP' — Questions on PR #278 Architecture

103 views
Skip to first unread message

Haraprosad Biswas

unread,
Mar 16, 2026, 3:42:13 PMMar 16
to dart-gsoc
Hi Helin, Phil, and the Dart team,

I'm Haraprosad Biswas, a Senior Software Engineer currently building an AI-powered fintech platform at TechCare Inc. (Canada) with real-time transaction processing and bank connectivity via streaming APIs. Prior to this, I was a founding engineer at 10xScale.ai where I led the full technical implementation of a cross-platform LMS and Hospital Management System — both involving real-time WebSocket communication, offline-first architecture, and FastAPI backends. I'm also the author of two open-source Dart packages: flutterfix (a CLI that auto-resolves Flutter/Android build errors) and flutter_tanstack_query (intelligent API caching with offline-first support).

I'm applying for GSoC 2026 and I'm very interested in the 'Prototype New Dart IntelliJ Plugin using LSP' project.

I've studied PR #278 carefully, including the review rounds from Angelo Zerr, DanTup, and the Gemini code analysis. I have three specific technical questions before I finalize my proposal:

1. LSP message framing
The current DartLanguageServerFactory uses a brace-counting loop to detect message boundaries — flagged by Gemini as a MUST-FIX since it breaks on any } inside a string value or when two messages arrive in the same read buffer. DanTup suggested reusing StreamMessageProducer from lsp4j which implements correct Content-Length framing per the LSP spec. Is this the direction you'd want the GSoC project to take, or are you considering a different integration point for message parsing?

2. LanguageServerFactory pattern
Angelo Zerr noted that extending LanguageServerDefinition directly is discouraged in lsp4ij — the correct approach is implementing LanguageServerFactory and declaring server + file mappings in plugin.xml. Is migrating to this pattern part of the GSoC scope, or is it being handled separately from the prototype work?

3. clientCapabilities forwarding
DanTup suggested capturing clientCapabilities from the LSP initialize request and forwarding them to the legacy analysis server via setClientCapabilities — so the server returns correctly-typed responses for completion kinds, symbol kinds etc. that lsp4ij expects. Should the proposal treat this as in-scope for the initial prototype?

My background in real-time streaming systems — bank transaction pipelines at TechCare, WebSocket sync in the Hospital HMS, IoT LoRa gateway integration — maps directly to the stream interception architecture in PR #278. I'll have a working fork ready by this weekend.

Thank you for your time — looking forward to your thoughts.

Best,
Haraprosad Biswas
GitHub: https://github.com/Haraprosad
Portfolio : https://portfolio-website-2f800.web.app/

Helin Shiah

unread,
Mar 19, 2026, 3:22:22 PM (11 days ago) Mar 19
to Haraprosad Biswas, dart-gsoc, Phil Quitslund
Hi Haraprosad,

Thanks for your interest in this project! Regarding your questions:
1. I think both options are worth investigating here. I was unable to get StreamMessageProducer to work on my initial draft, but this does not mean it's not possible. Some thoughts on the right place to pass data to and from the analysis server for an incremental migration would be helpful.
2. For the purposes of the proposal this can be considered in scope. It could be that some work will proceed on this before the GSOC work period starts, but also potentially not.
3. I think clientCapabilities is fairly well understood and more straightforward, so the omission in the PR is an implementation detail and not an item that needs high-level investigation.

--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/d85a2c78-1936-4e3d-94bf-742f315af31fn%40googlegroups.com.

Haraprosad Biswas

unread,
Mar 20, 2026, 10:39:12 AM (10 days ago) Mar 20
to Helin Shiah, dart-gsoc, Phil Quitslund
Hi Helin,

Thank you for the detailed response — this is exactly the clarity I needed.

I've already cloned the repo, got the project running locally, and started working on the lsp-over-legacy2 branch.

On point 1 (StreamMessageProducer): I'm actively investigating where the integration breaks down. My current hypothesis is that StreamMessageProducer may have difficulty with how the stream data is routed between the legacy handler and lsp4ij in the current architecture — but I want to confirm this by working through the code before making a strong claim. I'll document both approaches — StreamMessageProducer vs the current interception pattern — with a concrete technical comparison and recommendation in the proposal.

On point 2: Understood — I'll include LanguageServerFactory migration in scope with the awareness that some groundwork may land before the coding period.

On point 3: Noted — treating clientCapabilities as a straightforward implementation detail, not a research item.

I'll share my working fork here before the proposal deadline.

Best,
Haraprosad Biswas

Haraprosad Biswas

unread,
Mar 23, 2026, 5:05:26 PM (7 days ago) Mar 23
to Helin Shiah, dart-gsoc, Phil Quitslund
Hi Helin,

Quick update as promised — I have a working fork ready and have opened PR #1 on the lsp-over-legacy2 branch:
https://github.com/helin24/dart-intellij-third-party/pull/1

Fork: https://github.com/Haraprosad/dart-intellij-third-party

What's working so far:
- Migrated to LanguageServerFactory pattern with declarative plugin.xml registration (addressing @angelozerr's feedback)
- LSP hover requests proxied correctly through the virtual stream provider
- Per-feature LSP toggle in Settings → Languages & Frameworks → Dart ("Use LSP for code completion") — lets users opt in while keeping the legacy analyzer as the safe default
- Dedicated DartLSPClientFeatures, DartLSPCompletionFeature, DartLSPDiagnosticFeature classes

Open research item — StreamMessageProducer integration:
I've been investigating @angelozerr's suggestion to override createLauncherBuilder and implement a custom MessageProducer/MessageConsumer rather than manual Content-Length parsing. The plan is to test this via a temporary DartLanguageServerDefinition, and if it works, open a PR to lsp4ij to expose the hook via LSPClientFeatures. @angelozerr has confirmed he'd review that PR. I'll document both approaches with a concrete comparison in the proposal.

I'll submit the full proposal before the deadline. Happy to discuss any part of this further.

Best,
Haraprosad Biswas

Haraprosad Biswas

unread,
Mar 24, 2026, 2:40:54 PM (6 days ago) Mar 24
to Helin Shiah, dart-gsoc, Phil Quitslund

Hi Helin,

Quick update — I've submitted my GSoC proposal before the deadline. It covers all five sub-issues under #207 (#288–#292).

Happy to clarify anything or discuss any part of the proposal further.

Best, Haraprosad

Reply all
Reply to author
Forward
0 new messages