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]
