RFC: arbitrary parameters for add_drive
Hi, one of the bugs we have (#1092583) is about the lack of query string for http/https URLs: there were patches about that (not merged yet), whose solution was to add a new optional argument "querystring". Another bug that I'm looking at (#1118305) is about setting initiator IQNs for iSCSI drives; a good solution IMHO would be add a new initiator-name parameter for this. Thinking more, I was realizing that keep adding more optional arguments to add_drive would make it a bit cluttered; for this, maybe a more flexible solution for this could be adding a single extra optional argument as hash-table (or list of "param=value") for all these rarely used parameters specific to different protocols. How would that look? Thanks, -- Pino Toscano
On Wed, Dec 02, 2015 at 02:10:52PM +0100, Pino Toscano wrote:
Hi,
one of the bugs we have (#1092583) is about the lack of query string for http/https URLs: there were patches about that (not merged yet), whose solution was to add a new optional argument "querystring".
Another bug that I'm looking at (#1118305) is about setting initiator IQNs for iSCSI drives; a good solution IMHO would be add a new initiator-name parameter for this.
Thinking more, I was realizing that keep adding more optional arguments to add_drive would make it a bit cluttered; for this, maybe a more flexible solution for this could be adding a single extra optional argument as hash-table (or list of "param=value") for all these rarely used parameters specific to different protocols. How would that look?
So that would be adding OHashtable, or using OStringList in some way? Anyway, yes, seems reasonable. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
On Thursday 03 December 2015 11:52:14 Richard W.M. Jones wrote:
On Wed, Dec 02, 2015 at 02:10:52PM +0100, Pino Toscano wrote:
Hi,
one of the bugs we have (#1092583) is about the lack of query string for http/https URLs: there were patches about that (not merged yet), whose solution was to add a new optional argument "querystring".
Another bug that I'm looking at (#1118305) is about setting initiator IQNs for iSCSI drives; a good solution IMHO would be add a new initiator-name parameter for this.
Thinking more, I was realizing that keep adding more optional arguments to add_drive would make it a bit cluttered; for this, maybe a more flexible solution for this could be adding a single extra optional argument as hash-table (or list of "param=value") for all these rarely used parameters specific to different protocols. How would that look?
So that would be adding OHashtable, or using OStringList in some way?
Yes, something like either of the above; what would you think to be the cleanest approach here? * OHashtable + better representing it is a string -> string association + native type for GObject, Go, Java, Lua, Perl, PHP, Python, Ruby - not ideal representation in C: either as list with key1,value1,key2,value2,.. or with specialized type - mapped as list of key1,value1,key2,value2,.. in guestfish, Haskell - mapped as list of tuples in Erlang, OCaml * OStringList + already available, in C and in bindings - would need manual extraction of values out of "key=value" elements - does not guarantee uniqueness of keys -- Pino Toscano
On Thu, Dec 03, 2015 at 03:32:42PM +0100, Pino Toscano wrote:
On Thursday 03 December 2015 11:52:14 Richard W.M. Jones wrote:
On Wed, Dec 02, 2015 at 02:10:52PM +0100, Pino Toscano wrote:
Hi,
one of the bugs we have (#1092583) is about the lack of query string for http/https URLs: there were patches about that (not merged yet), whose solution was to add a new optional argument "querystring".
Another bug that I'm looking at (#1118305) is about setting initiator IQNs for iSCSI drives; a good solution IMHO would be add a new initiator-name parameter for this.
Thinking more, I was realizing that keep adding more optional arguments to add_drive would make it a bit cluttered; for this, maybe a more flexible solution for this could be adding a single extra optional argument as hash-table (or list of "param=value") for all these rarely used parameters specific to different protocols. How would that look?
So that would be adding OHashtable, or using OStringList in some way?
Yes, something like either of the above; what would you think to be the cleanest approach here?
* OHashtable + better representing it is a string -> string association + native type for GObject, Go, Java, Lua, Perl, PHP, Python, Ruby - not ideal representation in C: either as list with key1,value1,key2,value2,.. or with specialized type - mapped as list of key1,value1,key2,value2,.. in guestfish, Haskell - mapped as list of tuples in Erlang, OCaml
* OStringList + already available, in C and in bindings - would need manual extraction of values out of "key=value" elements - does not guarantee uniqueness of keys
OHashtable obviously .. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
participants (2)
-
Pino Toscano -
Richard W.M. Jones