On 8/15/2013 9:46 AM, John Mazzitelli wrote:
> The question is this: As a bundle creator, is it OK to
distinguish
> between "New Bundle" and "Upload New Version for Existing
Bundle"?
> Basically, can you answer that question up front when uploading a bundle
> distribution file. Is this the initial bundle version or is it a new
> version for a bundle already in the system?
>
> If that distinction can be made, RHQ will likely ask you to make that
> distinction. If not then RHQ won't ask, but it will make things more
> clunky internally, and possibly in the wizard as well.
I'm going to poison the well and put my opinion out there. Others are welcome to
oppose my thinking, but here goes.
It is very convenient to allow the user to simply upload a bundle distro file - any
bundle distro file - and let the system simply determine the right thing to do. There is
no real reason (from the user perspective) why the user HAS to let the system know
"this is the very first version of a new bundle" versus "this is a
subsequent version of a new bundle". If you force them to do this, now they will not
only have to know that, but, if it IS a subsequent version to an existing bundle, they
will have the new burden of searching through the set of visible bundles, selecting it,
and then pressing the "new version" button. Takes additional time and additional
clicks and therefore is not as user friendly.
Well no, they do not need to select the bundle for which this is a new
version. They only need to know if this is a new bundle (version 1)
upload or an existing bundle (version 2..N). It's just a distinction
between those two options, you don't have to be in the context of the
existing bundle to upload the new version.
Secondly, it still doesn't solve the problem. The problem that you are trying to
solve - avoid having the server receive the full distro file, crack it open, parse the
recipe, and determine if its a new bundle or existing bundle - is still unavoidable.
Because, now you have to confirm if the user really selected the correct bundle in the
first place. If the user selected Bundle A, clicked "New Version" - the server
still has to receive the full distro, crack it open, and parse the recipe to confirm the
user was right, that this really was for Bundle A. Because it is not, if its for Bundle B,
the server must error out - it cannot continue. The user will then be told a very annoying
message, "you selected bundle A but you gave the server bundle B - please select the
correct bundle and try again".
No, this is not true, see above. The issue you mention is the crux of
the problem, though. We don't know if the actual distribution file is
for an existing bundle until the file is sucked in by the server,
cracked open, the recipe is parsed and the bundle name is found. Then
we can figure out if the bundle already exists or not.
The problem we have is that unless the user has significant global
permissions, we will fail being able to create a new bundle without
bundle group assignment. So we upload this potentially large file to
the server, crack it open, and fail because it's for a new bundle and we
didn't ask the user for initial bundle groups that it should be in.
Even if we cover up this failure in the Wizard, we'd then have to go
back and ask them for the initial groups, and then try again, uploading
again the potentially large file.
This failure, and a lot of code complexity can be avoided if the user
can answer the question up front: New bundle or New version for
existing bundle.
So, you still must error out and ask the user to send the distro a second time, because
of either
That error out and second upload causes complexity and potential
slowness for large files.
a) they don't have the proper security credentials to submit a bundle that is
unassigned
or
b) they selected the wrong thing in the UI
Again, they don't have to select an existing bundle, just select the
one option. Of course if they hit the wrong option they will get an
error. Something like "Bundle already exists, can't create new bundle"
or "Bundle does not exist, can not add new version".
Either way, the problem stands. But in the case of b) you made them go through extra
annoying steps that they didn't have to do before and shouldn't have to do now. In
a) you made them go through extra steps because they attempted to do something that they
weren't allowed to do. I submit it is better to make them do extra steps because they
violated security constraints - it is more user friendly to not make them select a bundle
(and potentially get it wrong, when the server can figure it out by itself) and upload
only to be told after upload a large file that they picked the wrong thing in the UI.
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-users