On 2014年06月06日 12:41, Paul Clarke wrote:
Royce, thanks for your very helpful reply...
On 06/05/2014 10:11 PM, Royce Lv wrote:
> The issues you mentioned are:
> 1. There is no convenient way to upload a image.
> 2. When image is uploaded, too complex to fix its permission and get it
> 3. Warning msg disappear too quickly to see.
> As 1 and 2 are related to a feature I'm working on, I want to share with
> you our proposal and see if you like it from view of user:
> 1. convenient way to upload image:
> (1) As flow of :
> ISO server--download-->your laptop--upload-->your server
> is too long, we will supply with a dialog to let users to fill a web
> link and kimchi server will downloaded from the ISO server. So the flow
> ISO server--download-->your virtualization server
> number of download sessions will be limited.
Will this allow for authenticated access (userid, password) as well?
I think so,
and for upload in (2), in the future it will need
authentication as well(I assume),
because this action is related to system administration.
If so, this sounds good to me. Some users may not be willing to give
Kimchi their credentials, so they will have to use the upload
interface you describe below. I think this is fine, and still better
If you are referring to credential in other website, I think currently
we will just cover some well known website without passwd validation,
such as fedora official ftp and so on.
> (2) An upload interface will also be provided if you want to upload ISO
> from your laptop.
> also number of sessions will be limited
Is the limit to avoid DoS attacks? Will you make the limit configurable?
we don't want network performance downgrade by too much upload
or download. Making it configurable is a great idea.
Regardless, this sounds good.
> 2. complex permission fix problem:
> A dedicate directory will created for ISOs, and this directory will be
> monitored, if an ISO is scp to this directory, monitor will call a
> script to change permission.
Will the monitoring be done passively, via inotify, or actively via
polling? If the latter, I worry about the performance impacts on the
system and the time gap between when the file has been completely
copied and when the permissions have changed so that the file is
usable. This gap needs to be as close to zero as possible.
I tend to use inotify
hook script to handle this so that we don't need
to periodically polling.
> and for 3,
> I think we can add a box to store historical error msg (10 items
> restored), so that user won't miss the latest ones.
I would prefer the message stay on the screen until explicitly
dismissed by the user. It already has the 'X' button for dismissal.
Is there a good reason _not_ to leave the message displayed
indefinitely? This is an error message for a failed action for which
remedial action must be taken by the user.
Your suggestion is reasonable, above is
just my humble opinion:),and I'm
not a UI expert, maybe you and our UI team can take a look at a more
nature and comfortable experience.