Tony Asleson
2014-04-15 17:13:30 UTC
I was thinking that it might be good to add a plug-in data field to each
class (system/disk/pool/volume/fs etc.) which would be preserved, but
not accessible to the client. This would allow the plug-in writer the
ability to leverage in anyway they want and its use would be optional.
To make this easy, we could limit it to a string type which is one of
the fundamental json data types i.e. easy to serialize for RPC. A
plugin writer could encode whatever they want in it.
It's difficult to say how it exactly could be leveraged, but I could see
how it could potentially make a plug-in writers life easier if they
needed a way to store some additional state data. One possible use
would be to use to store the full cim object path for smi-s. Gris had
come up with another way to handle this, but this is one possible use too.
Does this sound like a good thing to future proof the API and make the
life easier for plug-in writers?
Thanks,
Tony
class (system/disk/pool/volume/fs etc.) which would be preserved, but
not accessible to the client. This would allow the plug-in writer the
ability to leverage in anyway they want and its use would be optional.
To make this easy, we could limit it to a string type which is one of
the fundamental json data types i.e. easy to serialize for RPC. A
plugin writer could encode whatever they want in it.
It's difficult to say how it exactly could be leveraged, but I could see
how it could potentially make a plug-in writers life easier if they
needed a way to store some additional state data. One possible use
would be to use to store the full cim object path for smi-s. Gris had
come up with another way to handle this, but this is one possible use too.
Does this sound like a good thing to future proof the API and make the
life easier for plug-in writers?
Thanks,
Tony