Transferring multiple files to phones with no unarchiver

[skuzzymiglet]

I'm opening this issue because:

• [ ] I have found a bug

• [X] I want to request a feature

• [ ] I have a question

• [ ] Other

• My Go version is: (paste the output of go version and remember that qrcp requires at least version 1.8 of Go)

go version go1.14.2 linux/amd64

• My GOPATH is set to: (paste the output of echo $GOPATH)

/home/skuzzymiglet/go

Zipping multiple files is a great feature but some really basic phones (KaiOS afaik) can't really extract zip files. I think it would be good to have a command-line option not to zip the files, such as --no-zip. I'm happy to make a PR if this isn't implemented yet

[skuzzymiglet]

Implementations:

• Multiple QR codes
• Serving a very barebones html pages with x download links

[claudiodangelis]

Hello @skuzzymiglet, thanks for proposing, I didn't consider the scenario where the user is missing an unarchiver app on the phone, you make a very good point.

About the possible implementations, I would exclude multiple QR codes. What I am thinking:

• sequential serving: once the first file in queue has been downloaded, the next one immediately starts without user intervention
• serving an html pages with download links as you suggest

The first option is fast and provides very nice user experience, the second may require a lot of clicks if many files are to be transferred. The second option could be also useful for implementing an "Directory Listing" feature, though it might be a bit out of scope.

What do you think?

[skuzzymiglet]

Yeah, true, html links are clunky (compared to just files) and the KaiOS browser is terrible with links, and directory listing is something for syncthing and the like, and not for a simple tool like this. I'm happy to help with sequential serving, it seems simple.

[skuzzymiglet]

Hey @claudiodangelis, I created a PR to add this feature, could you review it?

[claudiodangelis]

I think the logic can be simplified so that we don't even need a flag for the sequential: sequential becomes the default, and "zip" overrides the default.

The logic would be something like this fake code:

payloads := getFromArgs(args)
if argsContainDir() || zipFlag {
    archive := zip.CreateFromArgs(args)
    payloads = []payload.Payload{archive.Filename}
}
// The Send method should now accept []payload.Payload
srv.Send(payloads)

In the following examples, "a" and "b" are files, "d" is a directory, and they assume that every argument is passed as an "payloads" slice, and qrcp sends each file by looping through the slice.

n	Args	Contains dir?	Zip flag	Logic	Outcome
1	a	false	false	all arguments packed into a slice	"a" is sent
2	a	false	true	all arguments are zipped, slice only contains resulting zip	zipped file is sent
3	a,b	false	false	same logic of n 1	"a" is sent, "b" is sent
4	a,b	false	true	same logic of n 2	zipped file is sent
5	d	true	false	same logic of n 2	zipped file is sent
6	d	true	true	same logic of n 2	zipped file is sent
6	a,d	true	false	same logic of n 2	zipped file is sent
7	a,d	true	true	same logic of n 2	zipped file is sent

Makes sense? Thanks for your effort on this.

[skuzzymiglet]

Seems quite logical actually, more natural (to go with Cobra's ideas). Once the srv accepts a slice, I'll implement that

[skuzzymiglet]

Hey @claudiodangelis, can srv accept a slice yet? If it does, I'll update my fork

[claudiodangelis]

Hello @skuzzymiglet, refactoring that to accept a slice may take some time, as the "send" logic must be refactored as well to implement the loop.

[skuzzymiglet]

Hey Claudio, I think I'll continue implementing this today or tomorrow. I'll just do the plain -s first, then I'll start implenenting your interface idea (with a loop). Whenever Serve takes slice I'll refactor accordingly

[claudiodangelis]

Sounds good, thanks for your help. I may be unresponsive for the next few days.

Claudio

[skuzzymiglet]

Hello Claudio,

I'm not sure this pull request would help. Most phones have unarchivers nowadays. I'm happy for others to finish of though