<div dir="ltr"><div dir="ltr">On Sun, Apr 25, 2021 at 11:10 PM <<a href="mailto:asterisk@phreaknet.org" target="_blank">asterisk@phreaknet.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I noticed earlier this week that app_adsiprog, app_getcpeid, and <br>
res_adsi are deprecated as of 16 and currently scheduled for removal in <br>
19. I thought maybe this referred to older or certain parts of the code, <br>
but I've since been corrected that it's actually all ADSI functionality <br>
that exists in Asterisk.<br>
<br>
I recognize that it's likely one of the lesser used Asterisk features <br>
out there, but I think it adds value and is functionality I'm looking to <br>
leverage more, making this inopportune timing. Removing this <br>
functionality and relying on patches to add it back in doesn't seem like <br>
a feasible long-run solution, so I'd like to see this functionality stay <br>
there to the extent that it's possible.<br>
<br>
At this point, Sangoma is not maintaining ADSI in Asterisk - which I am <br>
perfectly fine with. It's not really something that I see evolving or <br>
changing in the future. That said, the functionality provides some <br>
utility and it would be a real shame if it were removed. This isn't like <br>
SIP, where PJSIP is theoretically a full replacement for it. It's a <br>
removal of functionality, which is very different, and limits what <br>
Asterisk can do. More capabilities increases its flexibility and power.<br>
<br>
In an earlier discussion on the Asterisk community forum, one takeaway <br>
seems to be that the cost of keeping it is essentially maintenance, such <br>
as making sure that new versions of GCC don't cause it to stop building <br>
and stuff like that. To the extent that I'm able to help with that, I'm <br>
happy to do so if that's what's required.<br>
<br>
Anyone else using ADSI or have any thoughts on this? If there are other <br>
painpoints, I'd be interested in hearing those, too. Thanks!<br></blockquote><div><br></div><div>While others think about this I would be open to keeping it in the tree, however if Sangoma becomes responsible for it again then it would be on the chopping block again. I think this would be done by keeping it in deprecated state however not removing it in a future version and keeping a note on the wiki page as such. This gives people notice that the module may be removed in the future at startup, and means that another deprecation cycle doesn't need to happen for it again if it goes into a truly unsupported state again.</div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>