[occi-wg] Incorporating units into OCCI

[Gary Mazz]

So, now I can order a new 10gigE card ? Opps, sorry a 125Mb/s ethernet 
card, or is that 10bit encoding ... a 100MB/s ethernet card, I forgot, 
they have compression on the circuit so, I'm sending text, thats 8:1 
compression and I'm sending binary thats 2:1 but binary only 20% of the 
traffic and 10 bit encoding so that's a 720MB/s ethernet card.  We can 
find the same issue in fibre channel and infiniband

Enough factitiousness... I've only had 4 hrs of sleep in 3 days.

Obviously common sense must be applied. There are common industry 
terminologies which should be respected. The DMTF spec calls out their 
CIM models with represent items in units other than bytes.

Presenting information in a form alien to the industry and role of the 
user only isolates the user from the technology, adoption is a critical. 
Companies spend a lot of money training their people both formally and 
on the job. If I was assessing a product to roll out. And, the product 
has different terminology than what my team was trained for, I would 
take a hard look to see how it affected my business processes.  I would 
need my staff to communicate in common terms, I don't need a product 
that will drive up my operational costs; cause me to retrain and reduce 
my production efficiency. I have made that decision against purchasing a 
product for that identical reason.

I'm not going to argue not representing everything in bytes. If there is 
consensus everything is one unit, go for it. I'll vote -1.You could win 
me over if you can find one of the cloud apis or network product 
marketed that allocates network bandwidth in bytes per second.

The real issue here is nearly everyone has a different set of 
requirements. Design decisions are normally driven by them. Since occi 
is racing to a goal, hard requirements are lacking.

Everything works out over time.

-gary


Andre Merzky wrote:
> Quoting [Gary Mazz] (May 26 2009):
>   
>> Andre,
>>
>> Maybe I've misinterpreted what was proposed? I though if a particular 
>> industry infrastructure, like broadcast and telecom, natively uses a 
>> terminology like bits, the spec won't support their native terminology.  
>> For example cable channels, satellites and  mpeg is commonly referred to 
>> bits.
>>
>> By not supporting the native units of an industry, you infer that is not 
>> an industry your specification recognizes. I'm sure that's not the 
>> intent, but that is how it may be interpreted.
>>     
>
> No, I think you understood correctly.  Still, you can't make
> all happy if you want to have a well defined and finite! set
> of units.  
>
> The units are supposed to be applied to disk space, memory
> size, and network bandwidth only - is the industry you are
> refering to specifying network bandwith in MBit/second?  I
> doubt it.
>
> Where would you stop?  Would you allow bit/minute?
> TB/decade?  That would mean free form units, yet another
> registry, and yet another set of conditions where
> implementations will fail to interop.
>
> Instead agreeing on a well known, fundamental unit which can
> trivially be converted to other, domain specific units,
> seems like an excellent and *simple* thing.  IMHO, we should
> do as was proposed: either use always bytes (or always bits
> if you want), or always KB, or MB, or [GB for disk, MB for memory,
> MB/s for network]. 
>
> I don't think some industry will feel ignored when we
> specify disk space in gigabytes...
>
> Cheers, Andre.
>
>
>   
>> -gary
>>
>>
>> Andre Merzky wrote:
>>     
>>> Quoting [Gary Mazz] (May 26 2009):
>>>  
>>>       
>>>> 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.
>>>>    
>>>>         
>>> I am not saying they are not important - but it does not
>>> matter on *which* one you agree, as long as we agree on
>>> something, and the spec is clear about that...
>>>
>>> Andre.
>>>
>>>
>>>  
>>>       
>>>> -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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     
>>>>>>>          
>>>>>>>               
>>>>>      
>>>>>           
>>>
>>>  
>>>       
>
>
>
>