On 05/09/2012 11:58 AM, Michael Pasternak wrote:
On 05/09/2012 11:46 AM, Ori Liel wrote:
why not having type in volume?,
because the different volumes would be entirely different entities not resembling each other
it's still works for our api, as non relevant properties does not shown in resource representation, we using this concept all over the api.
properties - yes, but I'm afraid the sub-collections might be different and we don't have support for that
sub-collections is the different story, you can create two volumes inheriting from same base class and return them according to the context, but this is implementation detail.
yes, but the question is why would entirely different entities will share the same type just because they are called in the same name in different projects. so gluster volumes is path of less resistance than trying to figure out how all future things which call themselves volumes will look like. we can revisit later and refactor/deprecate carry some backward compatibility as relevant.