>Joann Ruvolo wrote:
>>
>> Trevor, thanks for the WebShell feedback. Here is a summary of the
>> WebShell problems based on your comments and those of others, and
>> responses.
>>
>> 2) Inability to restore inactive versions of files.
>>    This sounds like an important requirement so we will look into this.
>>    Unfortunately with the lack of a real ADSM API these sort of
>>    features are awkward to implement.
>>
>>
>I'm not too sure what you mean when you say 'lack of a real ADSM API';
>I thought that the Webshell would have access to the full api.
>Nevertheless, yes it is an important requirement. But I guess it is the
>old 80/20 rule; 80% of restores are typically going to be the latest
>version.
>

The 80/20 rule is not really applicable in a Notes environment.  You might have
someone who has accidentally deleted a file 4 days ago, and didn't realize it
until today.  However, ADSM has made 4 backups of that same database since then,
because even if no one added or deleted any documents to that database in four
days...which is unlikely...Notes changes the Date and Time stamp of all database
files even if it does nothing to them.  Therefore it would fall into the
category of eligible when ADSM runs an icremental backup.

On the password issue, I could live with the crude password file.  Maybe make it
a little easier to create the password file.  Even if you're on an a secured NET
such as an Intranet, you wouldn't want just anybody out there backing up and
restoring what you have.  On the other hand like someone else said.  If they do
compromise a password...there's not much they can do.  Backup a file or restore
a file on a remote location.  Hypothetically, they could restore a backup as a
way of covering up something they did that day in say a log file.  I really
don't have much use for a user specific password, which allows them to restore
their own filespace.  They've never had that functionality before.

David W. Killingsworth