RFD: Resume existing sessions

[josevalim]

This document proposes the addition of a 'session/resume' command to allow users to resume existing sessions without returning previous messages, addressing the limitations of the current 'session/load' command.

[benbrandt]

Apparently I have a lot of thoughts on this one :D but I am not fundamentally opposed to offering a simpler load experience

[josevalim]

@benbrandt thank you for the feedback. Our discussion made me think about another angle we could approach "session/resume": if we have "session/resume", then we can implement "session/load" through a proxy that stores the data and converts "session/load" into "session/resume" operations. With this in mind, I am convinced "session/resume" is the primitive we want to aim for, and "session/load" is an optional affordance in case the agent exposes its own data.

I was on the fence about this proposal but, after this batch of feedback, I feel confident it is the right way forward!

[benbrandt]

@josevalim agreed. I think obviously there are richer alternatives, but having at least a "resume" as a minimal affordance would already be a win for Zed in terms of the current failure case of having no way to pick up a session again.

We could at least show the fact that we can't show previous history, but you could at least pick up knowing where you left off.

I think it's a nice primitive and I think composed with something like #243 there could be some nice shared primitives for agents who don't implement this themselves

[benbrandt]

Thinking about this some more, I think having this as a separate method provides a few benefits:

• for clients that for whatever reason don't want the history, they can just resume
• for agents that can only supply resume, a proxy on top could provide load on top of it, but the agent is still clear on what it supports
• for agents who support both, it should be trivial to use the same resume functionality, they just either replay events or do not

By having it as separate methods it is also clear which behavior you'll get.

@anna239 do you have any thoughts on this?

[anna239]

@benbrandt agree, let's go this way and we'll be able to add additional parameters to session/load later if we decide to do so, but current solution will provide some instant benefits

[josevalim]

@benbrandt I have updated the FAQ and the proposal with the latest feedback. In my opinion, this is good to go. The only open question is if the capability is resumeSession: boolean or resumeSession: {}.

[benbrandt]

Thanks for the updates, will merge and move to Draft stage!