Roadmap (for discussion)

[ijlyttle]

I am starting to wrap my head around what boxr is doing, so this might be a time to discuss a roadmap

boxr 0.3.5

The idea here is to focus on the documentation:

• harmonize the documentation
• polish the pkgdown site (hex logo!)
• preemptively address CRAN concerns about writing to the user's workspace

boxr 0.3.6

The idea here would be to refactor using the existing package-API:

• bring more automation to testing (ask Box about letting us use an account that allows more API calls, to support simultaneous testing against different versions of R)
• see if we can write a single function to access the Box API, then have all the other boxr functions call it (this may be ambitious)
• incorporate glue and fs
• id helper functions
• assess dependencies, perhaps making rio a "suggests"

boxr 0.4.0

The idea here may be to build a new API for the file and directory functions, based on the fs function-naming scheme. We would keep the existing API, perhaps soft-deprecating it.

As a first idea:

Directory functions: box_dir_ls(), box_dir_info(), box_dir_upload(), box_dir_download()
File functions: box_file_upload(), box_file_download(), box_file_history(), box_file_describe()
Trash functions: box_file_delete(), box_file_restore(), box_dir_delete(), box_dir_restore()

[nathancday]

I like the idea re-evaluating dependencies for 3.6. I'd like to build out the case for adding glue and fs, I feel adding new dependency would be need to bring tangible reward. If rio wasn't a dependency the read functionality would take a big hit and I do think reading directly from Box is a great feature. I think we might be able to trim out some other existing ones too.

For 0.4.0 I agree about shooting for data.frame returns, like fs. Doing the pattern box_ls() %>% as.data.frame() has always struck me as clunky. Just to bring time lines to this

• 0.3.5 - As soon as rio goes?
• 0.3.6 - Q4 2019?
• 0.4.0 - Q4 2020?

Totally shooting blind there, but wanted to add some calendar for discussion.

[ijlyttle]

I don't think moving rio to "suggests" would not cause us to lose any functionality - if you use box_read() without rio installed, you would get an error and be encouraged to install rio. It would make the installation lighter for those who use only the filesystem capabilities.

With glue and fs, these are low-dependency themselves, and are becoming standard building-blocks in the tidyverse. Recent PR's to tidyverse packages now encourage their use.

As you know, glue makes paste operations much-more-readable (making our jobs as programmers and debuggers easier); fs offers us a "standard" way to access the filesystem, which we do a lot in this package.

On the timetable, your guess is as good as any :) - but I appreciate you bringing it up.

For the 0.3.6, I see the pressing issues as:

• rio goes to CRAN, as you point out
• we sort through the functions that write to the filesystem (Here's the CRAN policy, search for "clipboard"):
  • For .boxr-oauth, make sure we get explicit or implicit permission (httr may already be doing this)
  • We should not write directly to .Rprofile or .Renviron. Instead, we should have the IDE open these files, then we write a message telling the user what to do. For example, see usethis. We may also have to wait for usethis to go again to CRAN.
  • This whole package writes to the filesystem, so... ¯\_(ツ)_/¯. Perhaps the user is implying permission to write to the filesystem by calling box_dl().

[ijlyttle]

Just to add some thoughts, perhaps to formalize a strategy for function-naming:

box_<subject>_<verb>_<object>

• subject can be one of file, dir, collab, or empty if the verb and object have only one possibility for subject.
• verb will be something like get, create, delete, ...
• object will depend on the function.

I know that we have a lot of functions that violate this, maybe we can agree on this going forward, and soft-deprecate and rename the non-conforming functions.

[nathancday]

Would this be box_collab_create_dir or box_dir_create_collab?

[ijlyttle]

thinking...

[ijlyttle]

I should have read (or remembered) my grammar concerning objects...

Let me try again:

box_<direct object>_<verb>_<other object>

• direct object can be one of file, dir, collab, or empty if the verb and other object have only one possibility for direct object. This is the thing being acted upon.
• verb will be something like get, create, delete, ...
• other object could be an indirect object, could be a prepositional object - depending on the function.

By this reasoning, box_collab_create_dir would create a collaboration object for a directory.

Does this work?

[nathancday]

Yea it works, but I'm not in love with any of these long file names. I wonder if box_collab_create(..., type = "file|dir") would be better

[ijlyttle]

I am with you on the names getting a bit much - bouncing off of your idea, how about something like:

box_collab_create(file_id = NULL, dir_id = NULL, ...)

such that exactly one must be provided. This might have implications for box_file_delete()/box_dir_delete() down the road. (on second thought, maybe this need not have implications for box_file_delete()/box_dir_delete()).

[ijlyttle]

Leaving a breadcrumb for discussion on collabs: #151 - will continue there