Discussion:
[Libstoragemgmt-devel] RFC: Add plug-in private data field to every class
Tony Asleson
2014-04-15 17:13:30 UTC
Permalink
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
Gris Ge
2014-04-23 10:20:43 UTC
Permalink
Post by Tony Asleson
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
With this, we can limit the length and format of XXX.id property.
This is much better than free form 'id' property.

I will provide a dome for this after API things done.

Thanks.
--
Gris Ge
Continue reading on narkive:
Loading...