On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
I thought Oleg asked for the use of the password?
Did you mean plugin?
I don't want there to be a way in 2.1.x and then it be completely
different in the 3.x line. It needs to be the same.
Certainly - would follow with an IT if we agree to have a CLI option
(and what the spelling should be :)
On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
With 2.1.0 imminent, we'll need to finalise on this soon - are the
current options satisfactory?
Cheers,
Brett
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 :)
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
