<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-05 21:16 GMT+08:00 Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Tue, 2 Aug 2016, Alex Xu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Chris have a thought about using ResourceClass to describe Capabilities<br>
with an infinite inventory. In the beginning we brain storming the idea of<br>
Tags, Tan Lin have same thought, but we say no very quickly, due to the<br>
ResourceClass is really about Quantitative stuff. But Chris give very good<br>
point about simplify the ResourceProvider model and the API.<br>
</blockquote>
<br></span>
I'm still leaning in this direction. I realized I wasn't explaining<br>
myself very well and "because I like it" isn't really a good enough<br>
for doing anything, so I wrote something up about it:<br>
<br>
   <a href="https://anticdent.org/simple-resource-provision.html" rel="noreferrer" target="_blank">https://anticdent.org/simple-<wbr>resource-provision.html</a><span class=""><font color="#888888"><br></font></span><br></blockquote><div> </div></div></div><div class="gmail_extra">Reusing the existing infrastructure of resource classes, inventories and allocations does make implementation easier with capabilities as well as their calculations and representations, at least at the beginning.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But I'm still not convinced by this direction, because it introduces unnecessary reuses as well as overhead for capabilities. Instead of attaching a capability directly to a resource provider, it needs to create an inventory and assign the capability to inventory, indirectly. Moreover, it reuses allocations and even the "compare-and-swap" strategy with the implementation of "generation" field in the resource provider. And it introduces further complexities and obscurities if we decide to disable the unnecessary consumable features for capabilities.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The existing architecture of resource provider is mainly for consumable resources. And we don't want capabilities to be consumable by mistake. It is an inherently different implementation for non consumable capabilities, so I tend to agree to implement qualitative part of resource provider from a fresher start to keep it simple and direct. And add features incrementally if they are thought necessary. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">---</div><div class="gmail_extra">Regards</div><div class="gmail_extra">Yingxin</div></div>