CLI Database Discussions

[vevy]

Use a unified text for the same type of warning in all applicable entries. A checkbox to show the template in the entry, so that if the wording is changed, the change is automatically reflected in all selected entries.

Easier contribution. Easier maintenance.

[vevy]

Expanding on the previous point:

You are right about the internet-facing tools. Perhaps I should add a "deal with care and keep your version updated" caution to any inherently-risky tool even if they are still being updated. Better do it now rather than chasing after them later.


I want to draw attention to a relevant point here: The vast majority of the ports are also available in Cygwin and MSYS2. Those versions are usually the most recent, the fastest in operation and the most dependable. We want to add the following phrase to all the relevant entries: "You can also get this from Cygwin and MSYS2." We have two options:

• Add it manually when we do each entry.
• Have a checkbox in the entry editing screen for Cygwin, one for MSYS2, and one for both. Or, for simplicity's sake, just one for both. This checkbox adds the phrase automatically to the entry in a specified area; for example: under an "Available in:" section. This option will require more work upfront (on poor Andrew of course ).

Now imagine that Cygwin changed their website for some reason or got hijacked or whatever. With option one, you will have to go to all the entries and update the entries manually. With option two, you make the change only once, or disable the section with a click.

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

entry_id	entry_date	parent_id (FK>entry_id)
123	2020	123
124	NULL	123

Code: Select all

SELECT a.entry_id,
       b.entry_date
  FROM table a
       LEFT JOIN
       table b ON a.parent_id = b.entry_id;

RESULT:

entry_id	entry_date
123	2020
124	2020

[Andrew Lee]

entry_id	entry_date	parent_id (FK>entry_id)
123	2020	123
124	NULL	123

Code: Select all

SELECT a.entry_id,
       b.entry_date
  FROM table a
       LEFT JOIN
       table b ON a.parent_id = b.entry_id;

RESULT:

entry_id	entry_date
123	2020
124	2020

Thanks for the tip! I will check it out soon.

[Andrew Lee]

Now imagine that Cygwin changed their website for some reason or got hijacked or whatever. With option one, you will have to go to all the entries and update the entries manually. With option two, you make the change only once, or disable the section with a click.

I am thinking this might be easier to implement with additional bbcode tags in the description field.

What do you have in mind in terms of presentation?

[vevy]

Thanks for the tip! I will check it out soon.

Sure. I hope it works alright.

Of course, this may facilitate other relations too. I'll try to figure out the simplest way to use it for multiple fields.

I am thinking this might be easier to implement with additional bbcode tags in the description field.

What do you have in mind in terms of presentation?

I'm still working out the best way to do a "Get it from" field(s). Like, for sure using parent entry ID, but allowing flexibility for entering versions (of the port), notes, etc without being too complicated. See the current entries to get my point. Unix ports are in the hundreds, but they won't end up the majority of tools, so, I don't want to crowd the edit/view with too many fields that most tools won't need.

If you mean for the warning templates, you can use an easy-to-do simple presentation for now. How they should look will be much clearer when we see them implemented, I think. I have some ideas to preserve space (like using icons/badges with the warning as popup/hover text), but I am not sure if that will be clear enough. I have a tendency to nanny the user, mind you!

[vevy]

[Moderator note: the discussion referred to below about about defining CLI and GUI were given their own thread.]

At this point I'd like to hear opinions from other people...

I had some notes but before I add more to that, would all parties be comfortable with a separate thread for the comparison of CLI vs. GUI discussion? There's starting to be a lot of subject overlap in this thread could confuse visitors.

Sure, a dedicated thread would be good.

You have my blessings!


While you are at it, could you move these to the CLI forums?
viewtopic.php?t=24525
viewtopic.php?t=381
viewtopic.php?t=22865

[Midas]

Could you move these to the CLI forums?

viewtopic.php?t=24525
viewtopic.php?t=381
viewtopic.php?t=22865

I disagree on the first case; the remaining two topics have been moved to "CLI submissions".

[vevy]

Could you move these to the CLI forums?

viewtopic.php?t=24525
viewtopic.php?t=381
viewtopic.php?t=22865

I disagree on the first case; the remaining two topics have been moved to "CLI submissions".

You are right! I had this in my notes for a while. I probably judged by the title.


------------------------
I said before I was going with 3 years to call a tool discontinued, but this seems too short to me considering the update intervals of many tools I have seen. I am going with 5 years. Does this work for you, guys?

[webfork]

I said before I was going with 3 years to call a tool discontinued, but this seems too short to me considering the update intervals of many tools I have seen. I am going with 5 years. Does this work for you, guys?

It's a great pleasure when I see tools come back from what I thought was dead status like Explorer++ or Asuite. I guess I can see some exceptions for an intensive alpha or beta process, but I think north of even two years without any developer activity is safe to consider discontinued.

Maybe it's a different standard for CLI developers, who knows?

[Andrew Lee]

If you mean for the warning templates, you can use an easy-to-do simple presentation for now. How they should look will be much clearer when we see them implemented, I think. I have some ideas to preserve space (like using icons/badges with the warning as popup/hover text), but I am not sure if that will be clear enough. I have a tendency to nanny the user, mind you!

I did mean for the warnings. I am thinking having new bbcode tags eg. [warningNet] or [warningCompression], which will expand into whatever text in the description.

[vevy]

but I think north of even two years without any developer activity is safe to consider discontinued.

There could be developer activity, but is more difficult to monitor that. I was talking more about releases. For example, you can see the jumps in time between releases with patch or make or sed.

Maybe it's a different standard for CLI developers, who knows?

I think that may be true, too. Remember the discussion about maintainability and how CLI tools tend to have a shorter path to maturity and stability than GUI tools.

[SYSTEM]

but I think north of even two years without any developer activity is safe to consider discontinued.

There could be developer activity, but is more difficult to monitor that. I was talking more about releases. For example, you can see the jumps in time between releases with patch or make or sed.

I agree. You examples show how e.g. patch has recently had releases around every 3 years.

I think it indeed takes around 5 years without releases before we can judge a CLI program dead. Like you said, they get into a mature state with little need for updates fairly quickly.

[vevy]

I did mean for the warnings. I am thinking having new bbcode tags eg. [warningNet] or [warningCompression], which will expand into whatever text in the description.

• As long as it satisfies "edit once, update all", the main point is achieved.
• It won't allow for filtering, but this can wait.
• Is there a way to use a predetermined placement (at the top) regardless of where the tag was entered in the description field?
• Maybe it can be given a visual distinction for the warning ones (like a grey background or so). We want it to be visible but not too stark, because we'd want the user to notice other, more-specific and more important warnings (avoid warning fatigue/indifference).
• You can use a drop list like that of text size in the forums: Tiny, Small, Normal, etc.

[vevy]

300

[Andrew Lee]

• As long as it satisfies "edit once, update all", the main point is achieved.
• It won't allow for filtering, but this can wait.
• Is there a way to use a predetermined placement (at the top) regardless of where the tag was entered in the description field?
• Maybe it can be given a visual distinction for the warning ones (like a grey background or so). We want it to be visible but not too stark, because we'd want the user to notice other, more-specific and more important warnings (avoid warning fatigue/indifference).
• You can use a drop list like that of text size in the forums: Tiny, Small, Normal, etc.

Which is why I wanted to see what kind of presentation you had in mind.

Correct me if I am wrong, but you and I seem to take polar opposite positions on this point, which is you prefer to have a lot of information or minutiae associated with each entry (everything but the kitchen sink approach), and everything should be filterable, whereas I am less enthusiastic about this approach.

My reasoning is that if you start overwhelming people with information they don't need, it is going to be off-putting to readers to editors alike. Right now, you seem to be want to add a lot of additional information without asking anyone else if they need it or will find it useful. And every other day, you dream up more fields to be added!