<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 20, 2023 at 5:06 PM Joshua C. Colp <<a href="mailto:jcolp@sangoma.com">jcolp@sangoma.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Jun 20, 2023 at 3:51 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">On 6/20/2023 10:32 AM, George Joseph wrote:<br>
> The one exception is the auto-generated documentation for <br>
> AMI/ARI/Dialplan.  That I'm starting to work on now.<br>
Thanks, George - I see from the README that one can run this on a local <br>
webserver. Will the auto-generated documentation aspect tie in with this <br>
as well? I wrote my own xmldoc to HTML generator a while back so I can <br>
view documentation for out of tree modules. If this can do that out of <br>
the box, then that would certainly be nice functionality to take <br>
advantage of. Will it just be sourcing from a core xml file, that we can <br>
point elsewhere if we want, or is that going to remain more upstream <br>
specific like it was with Confluence?<br></blockquote><div><br></div><div>I don't know how George plans to approach it fully, but ultimately the reference documentation will also end up as markdown and consumed with mkdocs. I do not expect those markdown files to be checked into the tree but generated as part of the deploy process. Any tooling to consume the XML and produce the markdown files will be available, so if someone wanted it locally they could.</div></div></div></blockquote><div><br></div><div>Each version of Asterisk generates between 800 and 900 pages of dynamic docs so it's going to take a bit of thought on how to integrate them.  As Josh noted, we don't want those markdown files checked into the repo but we do want mkdocs to integrate them seamlessly into the main docs site, including the search indexing.   We could run a full site build once a night to convert the static and dynamic pages into html and index them all BUT we don't have server-side searching available so it's done in the browser and right now, even without the dynamic pages, the search_index.json file is 4.1MB.  This might make it prudent to create a "virtual" site with its own index just for the dynamic docs and link to it from the main site.   Maybe even a separate virtual site for each Asterisk version.   In fact, there are tools to create a versioned API site already available.  Kind of like how Python does it with a drop down at the top of every page to select the Python version you want to see the documentation for.</div><div><br></div><div>Stay tuned!</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div></div></blockquote></div></div>