Hi Frase, Don't worry, I'm not justifying it - at least as long as the legacy store is present in Qpid, the options should IMHO stay. I was just trying to point out that using the --argument option seems to me to be more "future proof".
Jakub On Sat, Apr 12, 2014 at 1:10 AM, Fraser Adams <[email protected] > wrote: > Hey Jakub, > yeah I was going to mention the --argument approach myself, but that > wasn't *really* the thrust of my argument, there are a whole bunch of > things that have had a lot of really good work put in to them, but > precisely zero documentation. it seems such a shame to me. Qpid is a great > project, but there isn't such a strong culture of documenting things, which > I personally feel sells the project rather short. Now if you have the time > and energy to follow the mailing list, jira, source code then you might > stand a fighting chance and lord knows I've reverse engineered a few things > myself, but I'm afraid a few things have started to push my buttons > recently, so I felt it was worth making a stand with my "users" hat on :-) > > Just because it's *technically* possible for you and I and a few others to > work around this by being creative with --arguments doesn't mean that we > shouldn't have some due process to formally deprecate features that we'd > like to remove and *document* the alternatives. > > "But any scripts using the old parameters will need to be modified. " is > precisely my point, there's likely to be quite a few people faced with > "imagine my surprise when......" > > I don't actually have an issue with "The best would be to use only the > --argument options for everything " if it was proposed on the user list, > voted on and deprecated over a couple of releases. It's more the "surprise" > effect of changing things in a breaking way without giving sufficient > notice that I have the real issue with (and did I mention documentation :-) > > Frase > > > On 11/04/14 22:38, Jakub Scholz wrote: > >> I believe you will still be able to use them through the --argument >> option, >> which allows you to to define whatever parameter, or? But any scripts >> using >> the old parameters will need to be modified. >> >> The qpid-config tool has a bit strange interface, as some of the options >> are accessible directly and some require the use of the --argument option. >> The best would be to use only the --argument options for everything, as >> that seems to allow quite a lot of flexibility for configuring objects and >> properties the qpid-config it self has no idea about. >> >> Jakub >> >> >> On Fri, Apr 11, 2014 at 7:37 PM, Justin Ross <[email protected]> >> wrote: >> >> Fraser, you're right. I think this request is just going to the wrong >>> place. This change cannot go to trunk until the legacystore is >>> deprecated >>> and then removed. Even then, it may be worth keeping the options around >>> in >>> a less visible fashion to support deployments with the older store. >>> >>> >>> On Fri, Apr 11, 2014 at 1:29 PM, Fraser Adams < >>> [email protected] >>> >>>> wrote: >>>> OK so I'm going to bite. >>>> >>>> is legacystore as its name suggests going to be deprecated? At the >>>> moment >>>> there seems to be two stores, neither of which seem to have any >>>> documentation that a user might reasonably use in order to figure out >>>> how >>>> on earth to get persistence to work with qpidd. Well that was the case a >>>> few weeks ago when I last looked, if it has improved then I apologise >>>> for >>>> the rant :-) >>>> >>>> I'd personally prefer holding fire on removing things from qpid-config >>>> >>> and >>> >>>> invest the energy in getting the documentation for qpidd persistence >>>> >>> into a >>> >>>> decent state (including something on the whys and wherefores of >>>> >>> legacystore >>> >>>> and linearstore). >>>> >>>> Moreover removing these options will instantly prevent this and >>>> >>> subsequent >>> >>>> versions of qpid-config from being able to control these parameters on >>>> an >>>> older broker (have you considered use cases where users have a mixed >>>> economy of brokers? that's pretty common in my experience). >>>> >>>> I personally think it's a bit unfriendly to be removing features without >>>> providing a deprecation notice (and the intention of this work should >>>> >>> have >>> >>>> been posted on to the user list). I might have missed it but I don't >>>> >>> recall >>> >>>> seeing anything about this on the user list or on a Jira? >>>> >>>> Sorry if this seems a bit shirty :-) for context I have a very large >>>> federated system and generally there are a couple of different versions >>>> despite my best intentions, I've been bitten in the past by qpid-config >>>> changes. >>>> >>>> I don't generally use persistence with qpidd myself, so parochially I'm >>>> not affected, but I do think that there's a principal here with respect >>>> >>> to >>> >>>> the wider community. >>>> >>>> Regards, >>>> Frase >>>> >>>> >>>> >>>> On 11/04/14 17:36, Ernie Allen wrote: >>>> >>>> ----------------------------------------------------------- >>>>> This is an automatically generated e-mail. To reply, visit: >>>>> https://reviews.apache.org/r/20262/ >>>>> ----------------------------------------------------------- >>>>> >>>>> Review request for qpid, Gordon Sim and Ted Ross. >>>>> >>>>> >>>>> Repository: qpid >>>>> >>>>> >>>>> Description >>>>> ------- >>>>> >>>>> Remove the two parameters --file-size and --file-count from qpid-config >>>>> >>>>> Currently, qpid-config allows specifying qpid.file_count and >>>>> qpid.file_size queue declare options, via --file-count / --file-size >>>>> command line options. These options become obsolete in 3.0 due to >>>>> linearstore, that does not offer/require similar parameters. >>>>> >>>>> Removing refereces to file-size / file-count in the broker will be in a >>>>> separate patch. >>>>> >>>>> >>>>> Diffs >>>>> ----- >>>>> >>>>> /trunk/qpid/tools/src/py/qpid-config 1586666 >>>>> >>>>> Diff: https://reviews.apache.org/r/20262/diff/ >>>>> >>>>> >>>>> Testing >>>>> ------- >>>>> >>>>> qpid-config --help | grep file- >>>>> <no output> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Ernie Allen >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
