The spec currently describes a set of "optional" ops (interrupt, lookup, load-file, completions, close). Some folks have questioned whether the spec has any real authority to dictate the shape of ops that servers can freely choose not to implement.
@alexander-yakushev raised this for interrupt and again for lookup: if it's optional, can the spec really say how it must work?
@technomancy floated a tiered approach, e.g. a tier-1 server implements everything in the spec, a tier-2 server implements only the four required ops, and suggested looking at how LSP handles its long tail of optional features.
My take:
- I think it's fine for the spec to define the shape and behavior of optional ops. Otherwise clients have no portability story, since they'd have to special-case every server.
- I like the tiered approach (required + optional), but we'll need consensus on what belongs in each tier.
The spec currently describes a set of "optional" ops (
interrupt,lookup,load-file,completions,close). Some folks have questioned whether the spec has any real authority to dictate the shape of ops that servers can freely choose not to implement.@alexander-yakushev raised this for
interruptand again forlookup: if it's optional, can the spec really say how it must work?@technomancy floated a tiered approach, e.g. a tier-1 server implements everything in the spec, a tier-2 server implements only the four required ops, and suggested looking at how LSP handles its long tail of optional features.
My take: