You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mccanne was recently experiencing Brim/Zed/Brimcap as a user and made a helpful observation. He was very pleased with how easy it was to use zapi at the CLI outside of the Brim app to perform operations on the Zed lake that's launched behind the app. But his brimcap CLI experience was not quite as smooth. One snag that slows the user down is that brimcap index needs to know the "brimcap root" that it'll populate. If a Brimcap user was working entirely independent from the Brim app, this might not be a big burden, and the recent enhancement #135 makes this even easier. However, for users that are combining their Brimcap CLI use with the Brim app (as we expect many users are doing), the user now has the burden of knowing the appropriate brimcap root path that's appropriate for their Brim install and making sure they specify it using the -root option at the CLI or set it in their config YAML and pointing the app Preferences setting at it.
The Custom Brimcap Configuration wiki article tries to make this as painless as possible by pointing the user at the appropriate section of the Brim Filesystem Paths article so they paste in the correct path. However, since that path changes per supported OS platform, it's still more effort compared to zapi which is able to find the backend over the well known network port & endpoints.
We've discussed this one as a group, and there's at least a couple approaches that might address this.
If the proposed "brimcapd server" ("brimcapd" server #105) were to one day exist, brimcap could communicate with it over the network similar to how zapi works today and hence avoid having to converge on common filesystem paths.
Brimcap releases could be wired with a default brimcap root that points to the same location that's used by the Brim app. We discussed a couple ways this might be achieved.
Since we make per-platform Brimcap releases, they could be wired to default to the same per-platform paths used by the app, e.g., $HOME/.config/Brim/data/brimcap-root on Linux, $HOME/Library/Application Support/Brim/data/brimcap-root on macOS, etc. If the user has Brim already installed, they'd be all set: Brief brimcap index command lines without -root options would put their output in the right place and the app could make use the index entries immediately. Even if they don't currently have Brim installed but were using Brimcap on its own, it's arguably as good a location as any (having "Brim" mentioned in the path seems helpful) and would allow the app to start making immediate use of it if they install the app later.
Brimcap could be wrapped in some kind of installer so it can have its own independent "user data directory" (e.g. maybe one with "Brimcap" in the path), and Brimcap that's bundled with the Brim app could point to that path instead.
There's surely other approaches to consider as well.
The text was updated successfully, but these errors were encountered:
@mccanne was recently experiencing Brim/Zed/Brimcap as a user and made a helpful observation. He was very pleased with how easy it was to use
zapi
at the CLI outside of the Brim app to perform operations on the Zed lake that's launched behind the app. But hisbrimcap
CLI experience was not quite as smooth. One snag that slows the user down is thatbrimcap index
needs to know the "brimcap root" that it'll populate. If a Brimcap user was working entirely independent from the Brim app, this might not be a big burden, and the recent enhancement #135 makes this even easier. However, for users that are combining their Brimcap CLI use with the Brim app (as we expect many users are doing), the user now has the burden of knowing the appropriate brimcap root path that's appropriate for their Brim install and making sure they specify it using the-root
option at the CLI or set it in their config YAML and pointing the app Preferences setting at it.The Custom Brimcap Configuration wiki article tries to make this as painless as possible by pointing the user at the appropriate section of the Brim Filesystem Paths article so they paste in the correct path. However, since that path changes per supported OS platform, it's still more effort compared to
zapi
which is able to find the backend over the well known network port & endpoints.We've discussed this one as a group, and there's at least a couple approaches that might address this.
If the proposed "brimcapd server" ("brimcapd" server #105) were to one day exist,
brimcap
could communicate with it over the network similar to howzapi
works today and hence avoid having to converge on common filesystem paths.Brimcap releases could be wired with a default brimcap root that points to the same location that's used by the Brim app. We discussed a couple ways this might be achieved.
$HOME/.config/Brim/data/brimcap-root
on Linux,$HOME/Library/Application Support/Brim/data/brimcap-root
on macOS, etc. If the user has Brim already installed, they'd be all set: Briefbrimcap index
command lines without-root
options would put their output in the right place and the app could make use the index entries immediately. Even if they don't currently have Brim installed but were using Brimcap on its own, it's arguably as good a location as any (having "Brim" mentioned in the path seems helpful) and would allow the app to start making immediate use of it if they install the app later.There's surely other approaches to consider as well.
The text was updated successfully, but these errors were encountered: