Slumber 3.0: More With Less

[LucasPickering]

I wrote a blog post explaining my thinking for a new Slumber release that will make some pretty major changes to the app. It's a pretty short read, so please check it out and let me know what you think. In particular, I'm looking for feedback on:

• General points of friction in the app, especially when first starting to use it
• Missing features that you'd like to see
• Third party tools that you would like to, or currently do, use with Slumber
• Parts of the app that you think fall short, and could be completed better by external tools

[LucasPickering]

@anussel5559 @ttytm You've both been engaged with the feature and design process in the past so I'm curious if you have any thoughts on this proposal. If you have some time and can read through the post please let me know what you think!

[ttytm]

Thanks for all the work you're putting into this, @LucasPickering!

• Offloading is a great idea, I fully agree that the benefits outweigh.

• Regarding the ease of learning Slumber, I found the learning curve to be minimal. For me, it felt like there was just one initial larger step - setting up the collection files. After that, the learning curve was imho tiny. The well-designed TUI made things intuitive to use.

  Having the collection files is a feature I wouldn't want to miss. However, allowing users to add requests/recipes via the TUI might make it easier to get started and provide a more gradual introduction to the tool.

  All in all I think it's not overwhelming as it is already.

• Regarding the choice of the config file format, I think opting for Lua over HCL could appeal to a broader user base. Lua is more widely used, so fewer people would need to learn a new "language." This choice could also support the goal of keeping things easier to learn and use.

[LucasPickering]

I 100% plan to keep the collection files and I want them to continue to be user-generated, that's a core principle of Slumber. I do like the idea of adding to the file via the TUI though. That's one motivating factor behind changing the config format, because there are no Rust crates to support programmatically modifying YAML while maintaining comments/order/whitespace etc.

I got very far with Lua but the stopper I hit with it is there's no good way to programatically generate a Lua file. This is important for the importers, including the Slumber 2->3 importer I plan to write. It's also necessary for programatic edits later. There are a lot of options out there for dynamic config files so I'm still evaluating.

[ttytm]

I see. The ability to programmatically generate the config would indeed be essential for such features. I really liked using RON in two Rust projects I was working on. It's straightforward to work with, and it embraces Rust's capabilities well. What do you think about using it for the configuration file?

[LucasPickering]

I like RON but I don't think it provides anything inherently different from YAML/JSON, it's just nicer to work with and more explicit. In particular there's no mechanism to import other config files, which is something I would really like to have provided by the config format so I don't have to implement it myself. It also lacks any concept of expressions or bindings, so it doesn't solve any code duplication problems.

I've been mostly working on 2.4.0 for the past couple weeks so I haven't thought about this in a little while, but I plan to get back into it next week.

[anussel5559]

I'll echo @ttytm and say I love that the tool is evolving (even that it's still getting attention) and secondarily really appreciate the outreach and ability to provide my opinion. Thank you, @LucasPickering!

Apologies for the slow reply here, but in general:

1. Breaking out to my own tools feels super powerful. It's already felt powerful being able to do so with chains - I can sign and generate a jwt for an outbound request without slumber needing to bake that functionality in. Being able to do so in other areas will be a big win.
   • I often share my slumber config with co-workers (been getting them in to using it!). One thing that's come to mind is: the config is built with a specific external tool requirement (and will require more of those when you move that direction) so it could be interesting to allow a config to self-declare it's required external tools to simplify the sharing aspect!
2. I'm not opposed to changing config format - definitely sounds like other languages carry some better benefits.

I haven't run in to a missing feature that I'd like to see (fwiw) - most of the time, if I need to do something particularly fancy, I can boil it up in to an external chain that runs a different tool I have or can install (jwt example above!).

[LucasPickering]

Awesome that you're sharing this with coworkers! This is exactly the scenario I had in mind when designing the collection format. I like the idea of declaring dependencies, although I'm curious exactly what you think that would look like. Let's say at the top of a file you define:

dependencies: [jq, curl]

I definitely don't want to get into the world of installing dependencies, so the best I can think of is to check for binaries with those names, and show a warning if they aren't present. What do you think?

As far as the chains, I'm really glad you've been able to do what you need, I figured command chains would be a good tool for solving a lot of variety of problems. I want to replace the chain system not because it's too powerful, but because I think it's not very user-friendly. I'd like to take the same concepts and repackage them inside a system that'd be more familiar to programmers (e.g. functions and expressions), and in the process hopefully that will make them more flexible and composable.

[anussel5559]

I definitely don't want to get into the world of installing dependencies, so the best I can think of is to check for binaries with those names, and show a warning if they aren't present. What do you think?

agreed - something a simple as checking for that binary and notifying the user seems like more than enough.

[LucasPickering]

@anussel5559 I like this idea, do you mind opening a separate issue for it? ty!

[LucasPickering]

After a few months of messing around with various potential collection formats, I've decided to punt on that for 3.0 because I still haven't found anything I'm happy with. Instead, the flagship feature for 3.0 will be command-based response querying. I'm hoping to have a beta version 3.0 available in the coming weeks.

I'm still following the principles from the original post, and I plan to replace the collection format at some point, but it's going to take longer than I had originally hoped. When the time comes though, there will be a YAML -> ??? importer, so upgrading should be seamless.