<div class="gmail_quote">On Tue, Aug 3, 2010 at 1:18 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

>     2. Jorge and I would suggest making the request chain longer when<br>
<div class="im">>        possible to simplify each part, while you would suggest collapsing it<br>
>        to reduce the number of hops.<br>
<br>
</div>I suggest only making it longer when it is necessary, don't require<br>
components to span multiple layers. Having all services as modules<br>
will will make it trivial to split layers as we need. I see splitting<br>
things into a longer chain as a pre-optimization, and in some cases<br>
not an optimization at all. For example, the overhead of splitting<br>
out a proxy layer for something like rate limiting may not make<br>
sense. The overhead of the proxy (two extra sockets, buffer copying,<br>
...) is fairly expensive compared to just having the check in the API<br>
endpoint directly (consulting a shared data store for current limit<br>
and increment current request type).<br></blockquote><div><br></div><div>It's a trade-off -- there is the overhead of extra sockets, copying, network bandwidth; but there is the benefit of the API endpoint having less code in it, less complexity, fewer variables in the same scope.  If you need to fix a rate limiting bug and I need to fix an API endpoint bug, we can work on completely separate pieces of code.  I think we're just seeing different sides of the trade-off as more important.  Luckiy, I think you just said in #openstack that WSGI meets your needs, so this may be a moot point :)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In the .png, imagine the separate boxes inside the API Endpoint<br>
box that represents the different steps, not as a single blob. :)<br>
I understand your concern about keeping the layers separate, and I<br>
completely agree we don't want any spaghetti code/arch coming out of<br>
this. I think place where we don't align yet is how these layers talk<br>
to each other.<br>
<br>
Thinking of the request as a state machine and a series of<br>
transformations, I think we all agree that the states need to<br></blockquote><div><br></div><div>Ah hah!  That does help.  Thanks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


be well defined and each state can depend on external services<br>
(like auth). Where I see our difference is how we go about the<br>
transformations from one state to the next. I'm advocating we keep<br>
this generic, and allow for in-process transformations, where the<br>
multi-layer proxy example is forcing a HTTP proxy layer for each<br>
transformation.<br></blockquote><div><br></div><div>Hooray again for WSGI solving this problem :)  In-process transformations that can become HTTP proxies as needed!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Once we get to load testing we should be able to get a good picture<br>
on what we need to break out, if anything. We'll want to capture some<br>
stats on out current production API traffic, see the limits of the<br>
new system, and go from there.<br></blockquote><div><br></div><div>Sounds good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>    Hope this helped and didn't muddy the waters,<br>
<br>
</div>It did, thanks for helping break things down! I think we're about on<br>
the same page now, I'm going to go look at how WSGI layers can stack<br>
to see if that is a good fit. :)<br></blockquote><div><br></div><div>Great :)</div><div><br></div><div>Michael</div></div>