[occi-wg] Incorporating units into OCCI

[Andre Merzky]

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.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>          
> >>>
> >>> 
> >>>      
> >
> >
> >
> >  
> 



-- 
Nothing is ever easy.