Page MenuHomeWrite.as

Support any WriteFreely instance
Closed, ResolvedPublic

Description

Overview

Users should be able to use the CLI with any WriteFreely instance -- not just Write.as.

This should involve a rebranding of the Write.as CLI to make it clear to users that the client works with any instance -- perhaps create a new writefreely executable in the cmd/ directory that shares code with the writeas CLI and only includes functionality that works on WF.

Implementation

  • Create a new .writefreely directory in the user's home directory
  • Add a -host or -h flag that allows user to specify which instance to interact with
  • When they successfully perform an action on an instance, save that information to a folder in ~/.writefreely:
    • instance directory: ~/.writefreely/[host]
    • posts: ~/.writefreely/[host]/[username]/posts.json
    • user data: ~/.writefreely/[host]/[username]/user.json
  • Future interactions with that instance should load the corresponding data from the instance's data directory

posts.json

Should contain the JSON array of posts returned in the data property from the /api/me/posts endpoint.

user.json

Should contain the full JSON object returned in the data property from the /api/auth/login endpoint (as currently happens when running writeas auth). This includes the access_token needed for all authenticated requests.

Questions

We should probably provide a way to indicate the default instance and username for CLI operations, so users don't have to include them every time.

Event Timeline

matt triaged this task as Medium-High priority.May 26 2019, 7:53 PM
matt created this task.
matt moved this task from Backlog to Next Up on the Write.as CLI board.

re: question about default

I'm thinking just something like ~/.writefreely/config.json, or config.ini, which could even be created during a setup sub command as well as edited manually.

This could also later store the preferences for font, ltr etc T585

Paying attention to this, since I'm likely to wind up using these config files in T571 as well. Let me know if I can contribute.

I will ping you if I need some help for sure. We may be able to share some code now that I'm moving most of the cli into a package separate from the binary.

Created WriteFreely CLI, so it's easier to track features that should be in only one client (or both). In this case, this is a WF CLI feature only.

I don't think we should store the posts.json and use it for subsequent requests. For example, when would it expire? There may be more posts on the remote or something may have changed.

I agree, storing posts.json comes with challenges. But, a few things:

  • The /api/me/posts call is expensive. Caching this data, even for 5 - 15 minutes, would go a long way to making the CLI more responsive.
  • We're going to need to figure out how to sync that information for {T584} no matter what.

But for this particular task, we shouldn't worry about storing it.

TODO: break this up into its own task.

I've got a weird issue, maybe it is by design.

I can not create a new anonymous post against my single user instance using wf. Which would be writeas in the other. The default Post command.

I've got a weird issue, maybe it is by design.

I can not create a new anonymous post against my single user instance using wf. Which would be writeas in the other. The default Post command.

I must be tired.. that is of course the obvious behavior as you wouldn't want strangers just posting stuff of a single user blog.

Just a heads up @robjloranger: noticed a bug in WriteFreely when testing this, and fixed it in #144. Basically the full collection URL wasn't getting sent back, so after publishing I'd see /matt/new-post instead of https://team.write.as/matt/new-post

matt added a project: Restricted Project.Aug 29 2019, 9:36 PM
matt moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.