Re: [mh] another idea still: delete orphan links on device

[Gregg L. <gr...@li...>]

Hi Marc,

Seeing your note caused me to think that I/we should think about 
creating a new "InsteonRedux" page that would document all of the 
candidate, planned and completed changes that are part of the new 
insteon code base.

If I do all of it, then (1) it may take a while as I'm also trying to 
make progress on the code base itself and (2) there is considerable risk 
that this and a fair number of other past requests get forgotten.

So, what I'm proposing is that you start collecting any of your desired 
changes/suggestions.  If you feel more energetic, then toss them into 
some new InsteonRedux wiki page.  Otherwise, I'll try to put a start at 
one together soonish.  The other advantage of such a page is that I'd 
try to use it to show progress (i.e., what changes/additions/etc. have 
been completed) as well as what a user should expect when it becomes 
available.  At some point, I would then separate out the various 
suggestions into: (1) planned, (2) tentative, (3) deferred and (4) 
blue-sky with the idea that everything in "tentative" eventually gets 
moved to one of the other.  An example of "blue-sky" is any desire to do 
away with the extra "surrogate" links that must be created to control 
KPL buttons. Of course, there are two sub-classes to "blue-sky" which 
are "maybe" and "definitely not".  The surrogate removal would be in 
"maybe".  "Read my mind and correct any typos" would go into "definitely 
not".

I'd encourage others to contribute to this as well once it gets created.

BTW: Personally, I care much more about "the what" than "they why".  If 
it's a reasonable request (i.e., it doesn't violate some aspect of the 
implementation) and it's effort seems commensurate with value, then I'll 
try to get to it.  Details surrounding expected operation are always 
helpful.

Marc MERLIN wrote:
> We should have a "delete orphan links" on a specific device.
> 
> Why?
> 1) delete all orphan links can be dangerous, especially since it has no
> dry-run option to show what it's supposed to remove an in my case it removes
> links with my motion sensor since it won't manage it as discussed earlier
> 
> 2) delete all orphan links can be slow and not necessarily something you
> might want if you have links you made by hand
> 
> 3) I have a KPL that isn't being hit by the delete all orphan links and I
> can't get mh to remove its links to my old PLM so I'm going to have to reset
> it and reprogram it, which is even more work :)
> 
> (yes, this could leave half links behind, but I'm fine with that)
> 
> Thanks :)
> Marc