[occi-wg] Incorporating units into OCCI

[Sam Johnston]

Gary,

Nobody's suggesting we leave units undefined - rather that we define them
globally, dropping the convenience (and complexity) of supporting multiple
units (e.g. Mb, Gb, Tb) for each parameter.

Sam

On Wed, May 27, 2009 at 3:06 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:

> I think units are a very important issue. More significant than
> atom/json/xlm discussions. I think someone pushed a satellite  into mars
>  over a foot/meter  discrepancy.
>
> What  if its an e911 or other emergency application running on a cloud. It
> really helps to reduce operational risk with a page of text in a spec.
>
> -gary
>
>
> Andre Merzky wrote:
>
>> Oh well...  - you can't make everybody happy.  At the end
>> one needs to decide on one of the options, and either way,
>> just getting rid of units (by defining them as fixed) seems
>> like a good solution.  As others stated: a UI can always
>> represent a more suitable version...
>>
>> A
>>
>> Quoting [Gary Mazz] (May 26 2009):
>>
>>
>>> Just as an fyi, media folks work in "bits"
>>>
>>> -gary
>>>
>>>
>>> Andre Merzky wrote:
>>>
>>>
>>>> Quoting [Sam Johnston] (May 26 2009):
>>>>
>>>>
>>>>>  a 4th option, which i rather prefer since the units stuff tends to be
>>>>>>  relevant to and consumed by humans via UI rather than machines via
>>>>>> API,
>>>>>>  is not to use units at all.
>>>>>>  <memory>2147483648</memory>
>>>>>>  either of the above is far easier to transform to and from non-XML
>>>>>>  representations, in my experience, with the latter being zero effort.
>>>>>>  a couple extra bytes won't harm us and we adhere to my first
>>>>>>  engineering rule: the best solution to a problem is not to have it in
>>>>>>  the first place.
>>>>>>
>>>>>>
>>>>>  Andy and I spent a few hours on the phone tonight getting ourselves
>>>>>  aligned and this was basically the conclusion we came to as well
>>>>>  (though we were talking about choosing e.g. megabytes for memory,
>>>>>  gigabytes for disk and gigahertz for processors).
>>>>>
>>>> I think that is a great compromise: simple format, + human
>>>> readable.
>>>>
>>>> Andre.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090527/bb259d4b/attachment.html