feat: abstract CLI Agent Handler #86
Conversation
There was a problem hiding this comment.
I think this is too large a change to make in one swoop.
The way I see it, we have two things we need to do:
- Refactor the existing codebase such that the HTTP handler only has to worry about a single interface that exposes the methods common to all agent implementations, e.g.
type AgentHandler interface { GetStatus(ctx context.Context) (*types.StatusResponse, error) GetMessages(ctx context.Context) (*types.MessagesResponse, error) CreateMessage(ctx context.Context, input *types.MessageRequest) (*types.MessageResponse, error) SubscribeEvents(ctx context.Context, input *struct{}) (<-chan Event, error) } A lot of agent-specific 'quirks' are currently handled in lib/msgfmt but this could be still used behind the scenes of the implementation.
- Once the above is completed, a new implementation of the above interface can use the SDK methods but expose them in the same way.
What you're doing right now is essentially both 1 and 2 at the same time, which is a lot at once.
# Conflicts: # lib/httpapi/server.go # lib/httpapi/server_test.go
| @johnstcn Thanks for the feedback. PS: I haven't exposed the |
# Conflicts: # lib/cli/msgfmt/msgfmt.go
| ✅ Preview binaries are ready! To test with modules: |
| ✅ Preview binaries are ready! To test with modules: |
1 similar comment
| ✅ Preview binaries are ready! To test with modules: |
@johnstcn fixed this. |
| ✅ Preview binaries are ready! To test with modules: |
2 participants
Description
This PR handles the Step 1 of the feedback mentioned here #86 (review).