example: simplify transfer example

[dignifiedquire]

Description

Breaking Changes

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh-blobs/pr/53/docs/iroh_blobs/

Last updated: 2025-02-21T09:49:03Z

[matheus23]

I like the node -> router rename, extracting the args into a variable with a comment in advance (and skipping the cmd), but I'm not convinced that parsing the args twice (once in main, checking the length and matching on args[0], then in e.g. receive again, checking the length again).
I think having a match like ["send", path] => ... or ["receive", ticket, path] => ... is much easier to read.
I'm also not super convinced that pulling out send and receive into functions is easier to understand. These are functions that are only called once, and in addition, they even have a hidden contract with the caller: E.g. in send it is assumed that args[1] won't panic, i.e. the args length had been checked before. Perhaps it would be better to separate the argument parsing in main from send and receive and pass the parsed arguments into these functions, if we want to preserve the split out functions.

[dignifiedquire]

I think having a match like ["send", path] => ... or ["receive", ticket, path] => ... is much easier to read.

I have never seen anyone use this to parse arguments tbh, and was very confused when I read it, which is why I changed it

[dignifiedquire]

but I'm not convinced that parsing the args twice (once in main, checking the length and matching on args[0], then in e.g. receive again, checking the length again)

well it's not reparsing, just checking in stages, given the information available

[dignifiedquire]

I'm also not super convinced that pulling out send and receive into functions is easier to understand.

that's fair

[matheus23]

I think having a match like ["send", path] => ... or ["receive", ticket, path] => ... is much easier to read.

I have never seen anyone use this to parse arguments tbh, and was very confused when I read it, which is why I changed it

Well, I guess the haskeller in me came out. But like, this is just pattern matching, right? What specifically was confusing? Isn't this a really nice way to match CLI args, it looks a lot like the writing down... well.. the pattern.

I mean, if others agree - fine, but IMO the pattern matching reads better.

[dignifiedquire]

Well, I guess the haskeller in me came out

🤣

But like, this is just pattern matching, right? What specifically was confusing?

the line before for the most part

let args = std::env::args().collect::<Vec<_>>();
    match &args.iter().map(String::as_str).collect::<Vec<_>>()[..] {

is really hard to parse and understand

[matheus23]

But like, this is just pattern matching, right? What specifically was confusing?

the line before for the most part

let args = std::env::args().collect::<Vec<_>>();
    match &args.iter().map(String::as_str).collect::<Vec<_>>()[..] {

is really hard to parse and understand

Ah okay, perfect. Can we improve that part and keep the pattern matching? 🥺

[dignifiedquire]

Ah okay, perfect. Can we improve that part and keep the pattern matching? 🥺

I'll try 😅

[matheus23]

@dignifiedquire would you agree with this set of changes?

This now

• renames node to router
• extracts out args_refs and explains it with a comment (and uses .as_slice() instead of &[..])
• skips the _cmd in the args
• generally uses let x: X = str.parse() instead of X::from_str
• uses std::path::absolute instead of .canonicalize (I seem to get errors with canoncialize?)
• uses blobs.client().export instead of tokio::io::copying the file out

---

I decided against extracting out the functions, and also opted for the pattern matching.

And I went for .finish().await? instead of just .await? on the progress structs. That one I'm not super sure on. I do think being explicit here is helpful. If people have this open in an editor, they can click on the .finish() and see where it comes from - or they can search on docs.rs for structs that have such a method and will see results.

Thoughts?

[dignifiedquire]

LGTM 🚢

[dignifiedquire]

And I went for .finish().await? instead of just .await? on the progress structs.

they both suck, I am fine either way, we will make this API better in the future (TM)

[matheus23]

Converting dig's approval into something that github accepts 🙃