My only comment is this: I don't want to have to remember how you guys have uniquely abbreviated password. "Enc" is fine, "passwd" is a guessing game, and I believe should be spelled out.
Paul On Thu, Feb 26, 2009 at 5:27 AM, Brett Porter <[email protected]> wrote: > With 2.1.0 imminent, we'll need to finalise on this soon - are the current > options satisfactory? > > Cheers, > Brett > > On 24/02/2009, at 1:41 AM, Brett Porter wrote: > >> >> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote: >> >>> >>> >>> Brett Porter wrote: >>>> >>>> >>>> I don't view this as a temporary measure - as my second comment said, >>>> you may need a password to get the plugin in the first place. How would you >>>> address this case? >>>> >>> I have never seen an environment where read-only access to central or >>> central replica is authenticated. Short of that it's just another plugin to >>> be downloaded and used. Or I completely missed the question? >> >> That's right, it's the situation I was thinking of. I was thinking along >> the lines of a vetted repository where direct use of central is not used. >> It's maybe still unlikely that would be authenticated, but I wouldn't rule >> it out. >> >> Thinking it through, to me this actually feels a more natural fit in the >> CLI now, along with the other settings-based operations, pretty much >> symmetrical with the location of the operation to decode the passwords in >> the settings file. For a user, manipulation of the settings file is >> generally a set-up task, before you do anything else. This location also >> makes it very snappy, not going through the whole plugin cycle, and had very >> little impact on the code since it was already mostly achieved through the >> sec-dispatcher and cipher. A plugin for this would see infrequent releases - >> perhaps none - which seems an odd evolutionary cycle for an independent >> piece of code. >> >> Not that tied to it being in the CLI if a suitable replacement is already >> in place, but I hope this is somewhat convincing :) >> >> Cheers, >> Brett >> >> -- >> Brett Porter >> [email protected] >> http://blogs.exist.com/bporter/ >> > > -- > Brett Porter > [email protected] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > 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]
