Dan Groves wrote: > There were two reasons why I decided to have the library do the > conversion into strings: > > a) Why should the library user care how the data is eventually stored? > b) it makes the library easier to use. > > I remember in the design document discussions we back on forth on how to > get and set data via the dladm_[get|set]_conf_field functions. I agree > that this method is not as extensible; however, does the increased > usability of the API offset the lack of extensibility? Remember that > the user can always convert the data to a string and use the string type > if there isn't an existing type.
true. >>> The library handles the conversion. I discovered there wasn't a one >>> to one mapping between SMF types and the types I proposed using to >>> store data. >> >> that's not a surprise. we store all kinds of data in smf that can't >> be represented in a binary form using their native types; ip addresses >> and mac addresses being two good example. it is a given that smf >> cannot possibly have a type for everything that one might want to >> store as a property. >> > > Right, I wouldn't expect that SMF would provide all possible types. > >>> The set operation is easy, but the get is not. Consider the case of >>> a VLAN id stored as a 16 bit integer, easy enough to convert to SMF?s >>> 64 bit integer type on a write, but how do I know how to convert back >>> on the read? So I would need to store extra type information in >>> SMF. As far as I can tell, the best way to do this is to move >>> everything up one level in the hierarchy: another option is to force the mapping of types that this interface provides to those in smf to be 1-1. the api consumer would then be required to do range checking specific to the property being handled, and cast to a more specific type if necessary. how feasible would that be? >>> >>> links are instances >>> link attributes are property groups >>> each property group has two values, one is the link attribute's type >>> and the other is the link attribute's value >>> >>> If someone has a better idea, I'd be glad to hear it. >> >> an alternative approach is to store everything as a string and have >> the consumers of the api do the conversion. i think this is also more >> extensible for future data that consumers of the api may want to store >> for which smf has no type. >> > > I don't see how this proposal prevents someone from doing that. true, the string is there as a catch-all anyway. -seb
