Middleware Improvements

[Zeoic]

I imagine not many people use the middleware feature, so this might not get much traction, but figured I would put down my thoughts anyway!

To start, I feel like it would be great if any parameter that doesn't have a value would have some find of set value such as "False" or "0". This would make scripting around the parameter easier as if the parameter is just empty it would change the order of the parameters. I have worked around this by just having $error last, and only using $title and $chapters before it, as they should never be empty.

My second suggestion is a live preview box. It would be very handy to have a box that updates live with some basic example of how the parameters will be parsed. This could help people know what to expect as the parameters for their scripts.

Lastly I had a couple of ideas for new simple parameters that would just provide a bit more useful information to a script:

- $chapter_list (or some other better name) which provides an array of chapters that are in the download job. From that array, a script could easily calculate the total number of chapters being downloaded as well as check if any chapters are missing on that source. This would help provide more information in, for example, a push notification letting the user know what chapters are being downloaded / were downloaded.

- $event, simply a parameter that returns which event actually triggered the script.

[Squidy]

Sorry for taking a minute to get back to you on this!

To start, I feel like it would be great if any parameter that doesn't have a value would have some find of set value such as "False" or "0". This would make scripting around the parameter easier as if the parameter is just empty it would change the order of the parameters.

If I'm understanding the issue properly, could this be worked around by using named arguments? For example, something like "--title=$title". Then you would know if it was empty because the assignment would be empty, and you don't have to rely on the ordering of the arguments.

My second suggestion is a live preview box. It would be very handy to have a box that updates live with some basic example of how the parameters will be parsed. This could help people know what to expect as the parameters for their scripts.

Added this to my notes, I totally understand how this would be useful.

- $chapter_list (or some other better name) which provides an array of chapters that are in the download job. From that array, a script could easily calculate the total number of chapters being downloaded as well as check if any chapters are missing on that source. This would help provide more information in, for example, a push notification letting the user know what chapters are being downloaded / were downloaded.

What do you think would be a a good way of representing the array? I would have to serialize the chapter list in some way, or maybe just have a bunch of separate arguments ("chapter 1" "chapter2" "chapter3" ...). What data pertaining to the chapters would you want to be included (just the URLs, or titles too)?

- $event, simply a parameter that returns which event actually triggered the script.

Finally added this in the latest program update! It'll be replaced with "queued", "completed", or "error" depending on what event was triggered.

[Zeoic]

Sorry for taking a minute to get back to you on this!

Right back at ya, I didn't check the forum for a couple weeks and missed your reply haha. Just saw the release notes from 11.9.0 and saw the $event token was added.

If I'm understanding the issue properly, could this be worked around by using named arguments? For example, something like "--title=$title". Then you would know if it was empty because the assignment would be empty, and you don't have to rely on the ordering of the arguments.

With the new $event token that was recently added, the script could adjust its argument order / expectations per event, which should help a ton here. Named events however would remove the need for that and simplify things on the script side.

What do you think would be a a good way of representing the array? I would have to serialize the chapter list in some way, or maybe just have a bunch of separate arguments ("chapter 1" "chapter2" "chapter3" ...). What data pertaining to the chapters would you want to be included (just the URLs, or titles too)?

When I asked about this I hadn't really thought through the delivery of the array very much, I can see it being a pain to implement and get rather messy. With powershell, you can just litterally have a comma separated array of strings, but that isn't viable with batch/CMD. That means it would very much depend on how the program is running the middleware as to which options for it are available.

Something that I think would be good to look into is passing along a JSON file of some sort. This could be that the program stores a JSON file for every "download job" that hasn't been removed from the queue box. You could then have a paramenter / token that provide the file path to that. The JSON file could then have as much or as little information about the download job as you want without needing to change the middleware parameters.

Another option for obtaining JSON formatted information could be a new parameter that passes along a download job ID, which the script could then use with a new flag on the hdoujin EXE file to get some JSON returned to it.

To answer the question on what data I would want, the chapter number that was downloaded would be the ideal, but I certainly wouldn't complain if more data like title and url were included haha. With the chapter numbers, lets say that chapter 52 of the 76 chapters that were just downloaded had failed or was missing, having a list where it is missing in it would be great, because then your script could act accordingly. I see this similar to how when you browse from a source on Tachiyomi/Mihon and the source is missing a chapter, it lets you know that the specific chapter is missing and will be skipped. So alternatively, a way to pass along missing/issue chapter information could work instead.