This may make the code a little cleaner, but it goes against the convention of what -- means in the rest of the GNU userspace and is going to cause a lot of confusion. I'm not too keen on having two separate "namespaces" for options exposed all the way to users. My preference would be to keep the user interface clean and be clever in the code because we have far more IOR users than we have developers. I had envisioned just allowing option parsers to exist inside the AIORIs, and any options that are rejected by the main ior options parser then get passed down to the backends. This allows backends to be self-contained a little better without forcing the burden on users. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

On Tue, Oct 2, 2018 at 11:56 AM Glenn K. Lockwood ***@***.***> wrote: This may make the code a little cleaner, but it goes against the convention of what -- means in the rest of the GNU userspace and is going to cause a lot of confusion. I'm not too keen on having two separate "namespaces" for options exposed all the way to users. My preference would be to keep the user interface clean and be clever in the code because we have far more IOR users than we have developers. I had envisioned just allowing option parsers to exist inside the AIORIs, and any options that are rejected by the main ior options parser then get passed down to the backends. This allows backends to be self-contained a little better without forcing the burden on users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#94 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLEEWBWEdkHVTv5mpUuhELxZ1bXCobFks5ug5qigaJpZM4XEWIk> .

namespacing the arguments is not exactly conventional but might be an option here: "ior -a HDF5 --hdf5.collective_md --mpi.somehint" ? On Tue, Oct 2, 2018 at 11:56 AM Glenn K. Lockwood < ***@***.***> wrote: > This may make the code a little cleaner, but it goes against the > convention of what -- means in the rest of the GNU userspace and is going > to cause a lot of confusion. I'm not too keen on having two separate > "namespaces" for options exposed all the way to users. > > My preference would be to keep the user interface clean and be clever in > the code because we have far more IOR users than we have developers. I had > envisioned just allowing option parsers to exist inside the AIORIs, and any > options that are rejected by the main ior options parser then get passed > down to the backends. This allows backends to be self-contained a little > better without forcing the burden on users. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#94 (comment)>, or mute the > thread > < https://github.com/notifications/unsubscribe-auth/ACLEEWBWEdkHVTv5mpUuhELxZ1bXCobFks5ug5qigaJpZM4XEWIk > > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#94 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1uypZt_tQlL6DURViloD4D5FU-xggpks5ug5xOgaJpZM4XEWIk> .

If I’m understanding the conversation, you-all are looking for a way to add custom (per-AIORI) options, in addition to to standardized “universal" options. How about something like this: (a) ior … —custom “option1=a, option2=this string, option3=etc” (b) ior … —custom option1=a,option2=“this string”,option3=etc These arrive at your (top-level) parser as a single string, which can then be handed off to a secondary, local parser. I’m not sure whether such local parsers might require access to the rest of the command-line options, but, if so, you could arrange to parse everything else first, so the secondary parser can examine state in the relevant aiori (etc), if it needs context. I’m not advocating this approach, just emerging briefly from my lurking to try to assist. Thanks, Jeff On Oct 2, 2018, at 11:03 AM, Rob Latham ***@***.***<mailto: ***@***.***>> wrote: namespacing the arguments is not exactly conventional but might be an option here: "ior -a HDF5 --hdf5.collective_md --mpi.somehint" ? On Tue, Oct 2, 2018 at 11:56 AM Glenn K. Lockwood < ***@***.******@***.***>> wrote: > This may make the code a little cleaner, but it goes against the > convention of what -- means in the rest of the GNU userspace and is going > to cause a lot of confusion. I'm not too keen on having two separate > "namespaces" for options exposed all the way to users. > > My preference would be to keep the user interface clean and be clever in > the code because we have far more IOR users than we have developers. I had > envisioned just allowing option parsers to exist inside the AIORIs, and any > options that are rejected by the main ior options parser then get passed > down to the backends. This allows backends to be self-contained a little > better without forcing the burden on users. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#94 (comment)>, or mute the > thread > < https://github.com/notifications/unsubscribe-auth/ACLEEWBWEdkHVTv5mpUuhELxZ1bXCobFks5ug5qigaJpZM4XEWIk> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub< #94 (comment)>, or mute the thread< https://github.com/notifications/unsubscribe-auth/AH22-QGFqL0cPi38vKHXSy7YAFnZv59wks5ug5xOgaJpZM4XEWIk>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#94 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1uyoKwQtPrSMNr9aDBRdglJiEFkC1tks5ug60ugaJpZM4XEWIk> .

On Oct 2, 2018, at 12:20 PM, Julian Kunkel ***@***.***> wrote: Jeff thx for suggestions. I reckon the most important part is to converge on a good way of inputting the strings. I believe that option handling you proposed is not best user-friendly but aims at low implementation effort. This shouldn't be the goal. Jeff Inman ***@***.***> schrieb am Di., 2. Okt. 2018, 19:15: > If I’m understanding the conversation, you-all are looking for a way > to add custom (per-AIORI) options, in addition to to standardized > “universal" options. > > How about something like this: > > (a) ior … —custom “option1=a, option2=this string, option3=etc” > > (b) ior … —custom option1=a,option2=“this string”,option3=etc > > These arrive at your (top-level) parser as a single string, which can > then be handed off to a secondary, local parser. > > I’m not sure whether such local parsers might require access to the rest > of the command-line options, but, if so, you could arrange to parse > everything else first, so the secondary parser can examine state > in the relevant aiori (etc), if it needs context. > > I’m not advocating this approach, just emerging briefly from my lurking to > try to assist. > > Thanks, > Jeff > > > On Oct 2, 2018, at 11:03 AM, Rob Latham ***@***.***<mailto: > ***@***.***>> wrote: > > namespacing the arguments is not exactly conventional but might be an > option here: "ior -a HDF5 --hdf5.collective_md --mpi.somehint" ? > > On Tue, Oct 2, 2018 at 11:56 AM Glenn K. Lockwood < > ***@***.******@***.***>> > wrote: > > > This may make the code a little cleaner, but it goes against the > > convention of what -- means in the rest of the GNU userspace and is > going > > to cause a lot of confusion. I'm not too keen on having two separate > > "namespaces" for options exposed all the way to users. > > > > My preference would be to keep the user interface clean and be clever in > > the code because we have far more IOR users than we have developers. I > had > > envisioned just allowing option parsers to exist inside the AIORIs, and > any > > options that are rejected by the main ior options parser then get passed > > down to the backends. This allows backends to be self-contained a little > > better without forcing the burden on users. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#94 (comment)>, or mute > the > > thread > > < > https://github.com/notifications/unsubscribe-auth/ACLEEWBWEdkHVTv5mpUuhELxZ1bXCobFks5ug5qigaJpZM4XEWIk> > > > . > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub< > #94 (comment)>, or mute the > thread< > https://github.com/notifications/unsubscribe-auth/AH22-QGFqL0cPi38vKHXSy7YAFnZv59wks5ug5xOgaJpZM4XEWIk>. > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#94 (comment)>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AE1uyoKwQtPrSMNr9aDBRdglJiEFkC1tks5ug60ugaJpZM4XEWIk> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.