Hi Karen,
Karen Tung wrote:
> Hi Keith,
>
> Thanks for all your responses. I have a few more questions/comments
> below.
>
> Keith Mitchell wrote:
>>
>>>
>>> 2.1.6: In the functional spec(section 3.2), it says that when the user
>>> exit the installer, it will display a small menu of choices. In
>>> this design
>>> specification, there's no discussion at all about how that small menu
>>> is displayed? What program is called to display that menu...etc..
>>> Please elaborate on that.
>>
>> See section 2.8.
> I read section 2.8. From that, I understand that the small menu is
> displayed
> by the application/text-installer:default instance. What I still have
> a question about
> is when the user choose "shell prompt", and when they are done with
> using the
> shell, how do they get back to the menu?
Ah, ok. In that case, they'd have to leave the shell ("exit").
>>
>>>
>>> 2.1.7: When reporting errors, will the error be reported
>>> immediately? ie: If I type an invalid value
>>> in input field1, will I be immediately warn about the error as I
>>> move my focus to another
>>> input field? Or will all the error checking be done when I try to
>>> click next?
>>> Also, will I be allow to go to the next screen if I got invalid errors?
>>> Please clarify in this section.
>>
>> Please see the UI spec. I will point to the UI spec again here.
>>
> Can you point me at exactly where in the UI spec have this info?
> I am not able to find information related to this.
It depends on the error, and is listed under the "Errors" section for
that screen in the UI spec. A good example is under partitions[1], which
indicates that some errors should be immediately printed on keystroke,
while some show up when the user tries to F2_Continue. Note that the
user can't continue if there are any errors[2].
>
> Errors
>
> 1. On keystroke when editing a partition's size: (the offending
> keystoke is discarded so that the size field remains valid)
> 1. An invalid charater is entered: 'Only the digits 0-9 and
> "." are valid.'
> 2. The size is greater than Avail: "The new size is greater
> than the available space."
> 3. A second decimal point it typed: 'A number can only have
> one "."'
> 4. More than one decimal place: "Size can be specified to
> only one decimal place."
> 2. F2 errors are displayed in the error message area. The error is
> removed when the user enters the next keystroke, such as up
> arrow, down arrow, F<key>, etc.
> 1. There must one Solaris partition: "There must be one
> Solaris partition."
> 2. The Solaris partition must be greater than the minimum
> size: "The Solaris partition size must be at least xGB"
>
[1]http://www.opensolaris.org/os/project/caiman/TextInstallerProject/UI_Specification/spec.html#partitions
[2]http://www.opensolaris.org/os/project/caiman/TextInstallerProject/UI_Specification/spec.html#design
>>>
>>> 2.1.7: Can you give an example on how one will get to this situation
>>> of making an invalid selection? If we are giving people choices, is it
>>> possible to always only give them valid choices?
>>
>> Most invalid selections are impossible situations (for example, the
>> UI spec calls for not allowing the user to even highlight a disk that
>> is not at least as large as the minimum size). The only example of
>> invalid selection I can think of would be trying to continue past the
>> partition screen without creating a Solaris partition.
>>
> For this situation, would it make sense to disable the ability to
> choose "next" until a Solaris partition is created?
Right, it will be impossible to continue to the next screen if no
Solaris partition has been created. I think this is a wording issue -
when I say "invalid selection" I mean that the user is *attempting* to
make a choice that wouldn't work, not that they made such a choice and
began installation.
>>
>>>
>>> 2.3.2.4: why is hostname part of UserInfo? That is not related to a
>>> user.
>>
>> Moving this to NetworkInfo.
>>
>> While I'm here, it makes more sense to change UserInfo to just be
>> name and password. InstallationProfile will have an array of UserInfo
>> (in the case of the Text Installer, only 2 UserInfo's will be in the
>> array - one for "root" and one for a single additional user).
>>
> I agree that having an "UserInfo" object with username and password is
> better. It is
> more extensible later in case other user attributes need to be
> added. I think we should add one more
> attribute to the UserInfo object. A flag or boolean to indicate
> whether this user is a regular
> user or a role. If people don't specify a user, the root user will be
> a regular user, and
> if they specify a user, the root user will be a role. The "rule" to
> determine whether the
> root user should be a role or not is determined by the type of
> installer, so, it makes sense
> to fill in that field when UserInfo object is created.
I think this is a good idea.
>>>
>>> 2.4 and 2.5: There is the Required Library Functionality and
>>> Non-Library functionality
>>> section. Why group them as such? Looks like some of the functions
>>> in both sections
>>> could be used by other installer as well. Will functions from these
>>> 2 sections be
>>> delivered as separate libraries or the same library?
>>
>> Functions in 2.4 Required Library Functionality should and will be
>> made available to other installers. Functions in 2.5 Non-Library
>> Functionality will be implemented and private to the Text Installer.
> This makes sense to me now. Can you add this to the spec, in case
> other people have the same confusion as me.
Yes, we will clarify this.
>> In the case of get_[min|recommended]_install_size, this data is read
>> from the .image_info file and is very small code, so it was decided
>> that it would be implemented internally via Python rather than going
>> through the overhead of a library call (that would likely dive
>> through a bridge to C code).
> Agreed that it is better to implement this directly in Python. This
> function should also be
> used by other installer, such as the GUI, so, should it be in the
> shared library?
The short answer is yes (and I'll move it up to the library
functionality section). The long answer is, since the code is so
trivial, it doesn't make sense to implement it in a single language and
force consumers written in other language to use a bridge, so there will
be an implementation in C, and an implementation in Python. C already
has this function in liborchestrator, so we will only be adding the
Python version.
>>
>>
>>>
>>> 2.5.5.4: Does "prep_transfer" include the actual transfer of bits?
>>> Based on the description
>>> in 2.5.8, I think so, but I think the choice of name is not so good.
>>
>> Yes, it's a bad name. I was trying to avoid a naming clash with
>> libti's do_transfer call, but prep_transfer is a misleading name.
>> Would "perform_transfer" be preferable?
> Yes, that is better.
>>
>>>
>>> 2.8.3: Since the grub menu will only contain 1 entry, the exiting
>>> grub_setup.py finalizer
>>> script will need to be modified. At this time, this script will
>>> insert at least 3 entries
>>> into the grub menu.
>>
>> The default value will be set, and timeout set to 0. In this way, it
>> is irrelevant how many GRUB entries are on the disk. However, I'd be
>> happy to file a separate RFE to enhance grub_setup.py to make adding
>> those entries optional - but strictly speaking, it is unimportant.
>>
> OK. Actually, there's no need to file a separate RFE. Alok filed one
> requesting similar feature: 10750
Yeah, I noticed that after I sent it. He beat me to it by about 4 days!
Thanks,
Keith
>
> Thanks,
>
> --Karen
>
