| 98 | | There seem to be three classes of arguments "against" slivers. First: the name sliver is confusing to people. We can change the name, but it probably won't help. Using a name that we're already using for something else (like resource, or component, both of which refer to physical substrate) might make the situation worse, rather than better. I think sliver is a good name. |
| | 98 | There seem to be three classes of arguments "against" slivers. First: the name sliver is confusing to people. Well, we can change the name, but it probably won't help. I think sliver is a good name, because it sounds like what it is---a piece of a slice---and it doesn't already mean something else. Other options proposed, like resource or component, might make the situation worse by promoting a confusion between virtual resources and physical resources. (I say this recognizing that they are sometimes the same thing, but that makes the confusion more confusing, not less.) |
| 104 | | The third argument merits a response. My response is: either the virtual resource graph is partitionable, or it is not. |
| 105 | | If the graph is not partitionable, then it is not partitionable across aggregates. Then there are only slices, and each aggregate must receive the entire graph for the entire slice. If we change any part of the graph, we must pass the new slice rspec to at least all aggregates participating in the slice. We can make this approach work for demos, but it will not scale to large slices, and it will not succeed in accommodating dynamic slices. And then somebody in another project will figure out how to describe a virtual resource graph in a way that makes it partitionable, and we will move forward again from there. |
| | 104 | The third argument merits a substantive response. My response is: either the virtual resource graph is partitionable, or it is not. If the graph is not partitionable, then it is not partitionable across aggregates. Then there are only slices, and each aggregate must receive the entire graph for the entire slice. If we change any part of the graph, we must pass the new slice rspec to at least all aggregates participating in the slice. We can make this approach work for demos, but it will not scale to large slices, and it will not succeed in accommodating dynamic slices. And then somebody in another project will figure out how to describe a virtual resource graph in a way that makes it partitionable, and we will move forward again from there. |
| 107 | | On the other hand, if the graph is partitionable across aggregates, then it is also partitionable within aggregates. I hope and believe that the graph is partitionable. Then the only question is whether the aggregate API permits any partitioning within an aggregate, at the aggregate's discretion. And why would the API prohibit that? Why would the API prohibit an aggregate from grouping and organizing the virtual resources that it serves? Why would the API prohibit an aggregate from breaking its virtual resources into slivers that can be operated on through sliver APIs? |
| | 106 | On the other hand, if the graph is partitionable across aggregates, then it is also partitionable within aggregates. Then the only question is: should the aggregate API permit any partitioning within an aggregate, at the aggregate's discretion? And why would the API prohibit that? Why would the API prohibit an aggregate from grouping and organizing the virtual resources that it serves? Why would the API prohibit an aggregate from breaking its virtual resources into slivers that can be operated on through sliver APIs? If the aggregate finds its resources to be not easily partitionable, then it can always choose not to partition them, and group all the virtual resources of a slice at that aggregate as a single sliver. It then has all the advantages of the current AM-API. |
| | 107 | |
| | 108 | Needless to say, I hope and believe that the virtual resource graph is partitionable. |
| 124 | | What we do know is that it must be possible to describe these new virtual resources using a semantic model, and that the description will be a graph of elements and edges representing relationships among the elements. And if we have a stitching architecture that can propagate labels across edges, then the graph will be partitionable. And if the graph is partitionable, then it will be convenient to partition it into regions in order to allow the possibility that we might use the aggregate API to operate on different regions independently of other regions. For example, we can add virtual resources to a slice by attaching a new region, without changing anything about the graph as it exists. And we can remove virtual resources from a slice by detaching a region, without changing anything about the rest of the graph as it exists. But we can't say in advance what the regions might represent, or what the various type-specific sliver APIs might be (except for the ones we understand now). |
| | 125 | What we do know is that it must be possible to describe these new virtual resources using a semantic model, and that the description will be a graph of elements and edges representing relationships among the elements. And if we have a stitching architecture that can propagate labels across edges, then the graph will be partitionable. And if the graph is partitionable, then it will be convenient to partition it into regions in order to allow the possibility that we might use the aggregate API to operate on different regions independently of other regions. But we can't say in advance what the regions might represent, or what the various type-specific sliver APIs might be (except for the ones we understand now). |
