Hi Sue,
I talked with Keith over the video conference today and asked
about the OO design of the Installer and if any UML had been used to help
design the curses work. Keith said he was not aware of any and would
benefit from seeing some examples and further as the Python curses code
is very procedural he wasn't thinking much OO design would be possible.
I took the draft Design Doc and modeled what seems to largely be C
prototypes and tried my hand at a Python OO approach. I've posted the
class diagram[1] and activity diagram[2] on the Caiman Text-Based
Installer Project page[3]. I'm afraid I strayed a bit from what UML
intends in some places but didn't have my pocket reference handy, so if
you're wondering what I was thinking, please ask. Otherwise, references 1
5Band 2 are pointers I used while drafting these.
While trying to follow the design document as best as possible and
filling in some details which I didn't see enumerated -- just difference
between procedural and OO designs (what are you thinking of basing your
classes on in particular) I did run across two terms I didn't have a good
idea how one might implement. Do you have an action plan for the
form_filed and list_field objects or has the code largely been done by the
Prototype in a fashion easily meld-able to Python?
Thank you,
Clay
[1]: http://www.agilemodeling.com/style/classDiagram.htm
[2]: http://www.slideshare.net/erant/uml-activity-diagrams
[3]: http://www.opensolaris.org/os/project/caiman/TextInstallerProject/
On Fri, 4 Sep 2009, Karen Tung wrote:
> Hi Sue and team,
>
> Great document with a lot of details. My comments are below.
>
> General comments:
>
> 1) In many sections of the document, I think it will be easier to
> read and understand if the details section of the function comes first, and
> then,
> all the input , output and errors. That way, the input, output
> and error makes more sense, based on one's understanding of
> what the function is doing.
>
> 2) It would very useful to have a diagram showing all
> the different pieces. How things flow, which of the different
> libraries will be used when...etc..
>
> 3) The document focuses on the new libraries and functions that will be
> introduced. It will be useful to list other install libraries that the
> text installer implementation will use, but will not need to modify at
> all, such as libti, and libtransfer, and libict.
>
> 4) There's no mention anywhere in this document that this will be
> a cpio-based install of everything on the media,
> not a pkg-based install. Additionally, user is not allow
> to select which packages to install or not.
>
> 5) Which package will the text installer be delivered in? A new package?
> An existing package? Where will the text installer program reside, and
> what's it's name?
>
> 6) Changes are made to the LiveCD and GUI installer so it is accessible.
> Will this design allow the text installer to be accessible as well?
> Do you know any changes is needed to make it accessible?
>
> Specific Comments:
> -----------------------------------
>
> - In the very beginning, before the Table of Contents
> The URL for the Text Installer project is not correct.
>
> - 2.1.2, last paragraph, second sentence, "subsequent screens will not
> need to "recreate" from scratch....."
>
> Does this mean each screen is not individually pre-drawn, but it is drawn
> at real time, and all needed data in the fields are re-populated at real
> time?
> Did we do any measurement on the amount of memory it will save to use
> this approach verses the approach of having each of the screens pre-drawn,
> and kept in memory? Also, did we make sure that the user experience of
> doing this real-time screen drawing will be OK for slower machines with
> smaller amount of memory(512MB), when the user goes back and forth
> between screens a lot?
>
> 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.
>
> 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.
>
> 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?
>
> 2.3.2: What about default keyboard and default language? That should also be
> included
> in the installationProfile object.
>
> 2.3.2.4: why is hostname part of UserInfo? That is not related to a user.
>
> 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?
>
> 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.
>
> 2.8.3: strictly speaking, 3 new files will be added to the SUNWdistro-const
> package.
> text_installer_x86.xml, text_installer_sparc.xml and text_generic_live.xml
>
> 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.
>
> Thanks,
>
> --Karen
>
> Sue Sohn wrote:
>> We have posted the design document for the Text Installer at:
>>
>> http://www.opensolaris.org/os/project/caiman/TextInstallerProject/design_doc_v1.4.pdf
>>
>>
>> Please review and provide comments by COB Tuesday, September 15th.
>>
>> Thanks,
>> Sue
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
