Document new API #3690

Closed
opened 2021-05-02 19:12:48 +00:00 by maylee · 5 comments
maylee commented 2021-05-02 19:12:48 +00:00
Owner

The documentation at /docs/frontends/webapi.rst needs to be deleted or rewritten after we replace the current API.

The documentation at `/docs/frontends/webapi.rst` needs to be deleted or rewritten after we replace the current API.
tahoe-lafs added the
documentation
normal
defect
n/a
labels 2021-05-02 19:12:48 +00:00
tahoe-lafs added this to the User Documentation Goals milestone 2021-05-02 19:12:48 +00:00
exarkun commented 2021-05-02 23:32:38 +00:00
Author
Owner

What problem would this rewrite address?

Also, the API it describes is bad and we should replace it with a new, different one.

What problem would this rewrite address? Also, the API it describes is bad and we should replace it with a new, different one.
maylee commented 2021-05-03 08:49:24 +00:00
Author
Owner

With that in mind, this rewrite can hold off until the API is replaced, and it would really be documentation for the new API. At any rate, whatever's at /docs/frontends/webapi.rst needs to be changed.

Ticket has been changed to reflect this perspective.

With that in mind, this rewrite can hold off until the API is replaced, and it would really be documentation for the new API. At any rate, whatever's at `/docs/frontends/webapi.rst` needs to be changed. Ticket has been changed to reflect this perspective.
tahoe-lafs changed title from Edit Web API documentation to Document new API 2021-05-03 08:49:24 +00:00
exarkun commented 2021-05-03 11:07:14 +00:00
Author
Owner

A better development workflow might be that every incremental implementation effort on the new API (which will certainly not be merged as a single, fully-formed thing) comes along with its own new chunk of documentation.

If so, the tickets we want are probably more like "New API for XXX" where "XXX" is stuff like "upload a file", "download a file", etc (these are examples; the new API hasn't been given much dedicated thought yet).

A better development workflow might be that every incremental implementation effort on the new API (which will certainly not be merged as a single, fully-formed thing) comes along with its own new chunk of documentation. If so, the tickets we want are probably more like "New API for XXX" where "XXX" is stuff like "upload a file", "download a file", etc (these are examples; the new API hasn't been given much dedicated thought yet).
maylee commented 2021-05-04 18:12:12 +00:00
Author
Owner

Noted, can we keep this ticket in place until those API changes take place?

Noted, can we keep this ticket in place until those API changes take place?
exarkun commented 2021-05-11 15:19:12 +00:00
Author
Owner

If it were just me, I'd close this. All documentation should be delivered alongside (and at the same time as) the implementation.

If it were just me, I'd close this. All documentation should be delivered alongside (and at the same time as) the implementation.
tahoe-lafs added the
wontfix
label 2021-05-11 15:25:47 +00:00
maylee closed this issue 2021-05-11 15:25:47 +00:00
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#3690
No description provided.