<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 12:03 PM, Michael Krotscheck <span dir="ltr"><<a href="mailto:krotscheck@gmail.com" target="_blank">krotscheck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Feb 25, 2016 at 9:38 AM Anne Gentle <<a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 24, 2016 at 9:53 AM, Michael Krotscheck <span dir="ltr"><<a href="mailto:krotscheck@gmail.com" target="_blank">krotscheck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Personally, I'm a fan of anything that removes the need to render HTML on the server. Static HTML is a great start. </div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Why is that a stated preference? Truly curious.</div></div></div></div></blockquote><div><br></div></span><div><div>Oh, lots of reasons, mostly coming from the JS UI + API architecture model. (Caveat: I think these rules are awesome for things that do not care about SEO. Documentation, however, really really cares about SEO).</div><div>- Separation of concerns and expertise. Let API people focus on API things, while UI people focus on UI things.<br></div></div><div>- Variability in velocity. Development on API's tend to slow down as they approach "Stable". Development on UI's continually tweak and update as design standards change.<br></div><div>- Freedom to build multiple UI's. Say, one that's simply descriptive, and one that's interactive. Maybe one that's mobile? If you start by having a separate API, why bother adding another server just to render HTML when the browser's perfectly capable?</div><div><br></div><div>The one rule that I feel applies to docs as well is performance: It's easier, and cheaper, to distribute static files across a CDN, than to host application servers in each global region. If the end result of a serverside application is going to be 'effectively static' content anyway (That is mostly text, with a few interactive bits that will be run out of the browser anyway), then there's no reason to worry about something serverside.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I have some tactical questions about the shipping needs of fairy slipper- how's it packaged, how's it built, etc? I notice that it's a munged python/javascript project, which goes against the best practices in the Project Team Guide - is there some effort to separate the two?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Since it's a dual-purpose tool (both migration and display) then yes, it's a bit conflated. Do you have suggestions for what to do to properly separate? Maybe I should meet with you next week to make sure I understand. Can we chat on IRC early next week?</div></div></div></div></blockquote><div><br></div></span><div>I don't know enough about the purpose of the project to really talk about the separation, to be honest. In fact, most of what I'm talking about above is me just bikeshedding about the magic world of apps, with no real understanding AT ALL about what y'all are up to. So, take my blathering with a grain of salt.</div><div><br></div><div>Also, I'm available 5AM-Noon PST most weekdays, tuesdays being crazy meeting day. And I will be very skeptical about anything that sounds like getting roped into yet another project ;)</div></div></div></blockquote><div><br></div><div>Oh, I won't come with a rope! :) We have been pondering whether we should just consume projects in the swagger-ui and OpenAPI community versus maintaining our own. So I'll pick your brain on that angle and all are welcome to chime in.</div><div>Thanks! </div><div>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>Michael</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
</div></div></blockquote></font></span></div></div>
<br>_______________________________________________<br>
OpenStack-docs mailing list<br>
<a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Anne Gentle</div><div>Rackspace</div><div>Principal Engineer</div><div><a href="http://www.justwriteclick.com" target="_blank">www.justwriteclick.com</a></div></div></div>
</div></div>