Opinion Poll: CLI Database Filters and Future

[vevy]

@SYSTEM Would you like to see a CLI site (gather all scattered CLI tools from all over the web)?
If so, what is the main point(s) that, if answered or addressed, will allow you to give filters a shot?


For example, you mention that adding batch files would bloat the database. I think they will be helpful.

But since they are labelled as batch files, it won't matter! Because a simple filter would let you hide them so they won't bother you!


That's what filters are about, only get the tools that serve your need.

----------------------------------------------------------------------------------------------

The question is also open to CLI aficionados and users in our site. I would like to hear your opinions. Don't make me name names!

[SYSTEM]

@SYSTEM Would you like to see a CLI site (gather all scattered CLI tools from all over the web)?

Somewhat.

I can already find CLI tools for things I need to do (I e.g. make some automated image transformations with ImageMagick, and recently renamed a bunch of files with Swiss File Knife). I can see the use for a CLI site, but on the other hand it's not very common I'd find myself thinking "hmm, I need to find a CLI program that does X".

If so, what is the main point(s) that, if answered or addressed, will allow you to give filters a shot?

There would need to be a situation where a search for a tool returns so many results that I need to filter them further, instead of just manually investigating the options one-by-one. In addition, there would have to be a situation where filtering would actually capture the difference between projects.

As an example, regarding the aforementioned ImageMagick, it has a fork called GraphicsMagick. The primary differences between these two are that IM supports more image formats and GM attempts more actively to avoid security vulnerabilities when used with untrusted images. Neither of these differences can be represented with a filter, and in any case it's very little manual effort to just research the projects one-by-one (especially if the differences are called out in the description).

For example, you mention that adding batch files would bloat the database. I think they will be helpful.

But since they are labelled as batch files, it won't matter! Because a simple filter would let you hide them so they won't bother you!


That's what filters are about, only get the tools that serve your need.

Bloat is more of a problem for people who maintain the database, not really for the users. My problem with batch files in the DB isn't that users would get them as search results, but more the effort it takes to create the entries, as well as to make the DB flexible enough to handle them (I don't expect batch files to have home pages and download links, for example).

[vevy]

Thanks for responding!

I can already find CLI tools for things I need to do (I e.g. make some automated image transformations with ImageMagick, and recently renamed a bunch of files with Swiss File Knife). I can see the use for a CLI site, but on the other hand it's not very common I'd find myself thinking "hmm, I need to find a CLI program that does X".

• Fair. Although, I want to make a distinction between "not my use case" (vote option 3) and "I oppose its implementation" (option 4).
• A side note: There is "tool-hopping" like distro-hopping, but there is also a benefit for optimization. One reason that moved me away from "I will use sfk for everything!" was that I found out it was slower at md5 hashing than other tools by >4x !

There would need to be a situation where a search for a tool returns so many results that I need to filter them further

I use search first. If you go in with a specific tool in mind or just want a working tool, search would probably be enough > 90% of the time.
If you are looking for an alternative, either using search or a listing (e.g a category page or a use case page), filters can be very helpful to narrow down potentially dozens of tools.

...In addition, there would have to be a situation where filtering would actually capture the difference between projects.
[...]
...Neither of these differences can be represented with a filter...

True. It would be very difficult to make use cases that deep. I try to be mindful of common use cases, and security vulnerability in an image conversion tool doesn't seem like a common use case that people search for.

But filters aren't necessarily supposed to cover every last use case/different. They help cover the main "differentiators" so that your search is more productive.

Example:

If you are researching ImageMagick vs GrahpicsMagick by names, filters won't help you much more than what you can do yourself. I agree with that.

• Lets say I have a particular need (a small, open-source, user-friendly tool for a particular format conversion (like this one juverax shared) to use in a script, vs a slower but capable behemoth that can handle any format thrown at it.

• But including all the different image processing/conversion tools, GraphicsMagick included, is what makes the need for filters. I can filter by license and format use case "jpg to pdf", then sort the 15 results that remain by size or date and then start researching.

• This will be much quicker than having to go through dozens or more of image tools:
  • looking one-by-one to see if the support jpg (or whatever format you want) as input and pdf as output
  • before you move on to see which are open-source,
  • then moving to the next step, and so on.
  You already do this filtering in you mind or your notes. I am trying to make it easier. I am sure you used Amazon or Newegg or similar sites and found their filters (price/rating/release date/type of RAM/size of cache/etc) helpful when looking for a potential item to research further.

Bloat is more of a problem for people who maintain the database, not really for the users. My problem with batch files in the DB isn't that users would get them as search results, but more the effort it takes to create the entries, as well as to make the DB flexible enough to handle them (I don't expect batch files to have home pages and download links, for example).

• Batch files using only Windows-included tools (since this can help you do without a 3rd-party tool). Otherwise, we would have a nightmare of a sea of files that's more confusing than helpful.
• They have a site link since we have to get them from somewhere. If shared by one of us, then link is e.g. post or such.
• They can have a download link or just host them here.
• Both these fields are optional.
• If anything, not having to fill such fields makes for easier maintenance, although it is not so difficult either way.
• They tend to get updated even less frequently than stable CLI tools. Often it is just the one "release".
• Effort is cumulative. Some batch entries for a clear use case are better than no entries!

[SYSTEM]

Yeah, "JPEG to PDF" use case is a more reasonable use for filters.

The main problem with use case filters is creating them. "Convert X to Y" creates a huge matrix of possible use cases. How are they all created, assigned to the right tools, and presented to the user?

[vevy]

The main problem with use case filters is creating them. "Convert X to Y" creates a huge matrix of possible use cases. How are they all created, assigned to the right tools, and presented to the user?

Great question that I have been thinking about! I have my ideas! Some for general use cases, others for automating the creation and manipulation of format use cases.

But one step at a time, lets first implement the basic foundation and see if we can move on to more specific use cases.

One simpler way to do it to split the matrix into input and output. here is a sneak peek at how it might be done :