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.