Clay Baenziger wrote: > Hi Jan and Dave, > I know, certainly, we need to think of a U/I to use for criteria > and manifest generation, so that a user doesn't have the pain which was > often associated with Jumpstart when a simple typo could cause an install > to fail and to hide them from my very generalized server/criteria format.
A well-designed UI would be nice, but it isn't a panacea. A number of users, who have spoken up in the past and undoubtedly will again, prefer and expect to be able to create manifests using their favorite editor. Usability in that context requires consistent, logical rules, obvious names, and natural data formats. Start there first, and you'll get a lot of bang for very little buck. Dave > I've tried drafting a very simple GUI to post on my blog to help > pains for the prototype user. It is just a mockup, but let me know if that > quells some concerns for November. > Be warned the NETWORK criteria causes the shell to print output > almost like memory corruption (try adding it with another criteria to > see); if you see the bug in my code, please let me know! Otherwise, right > now instead of gracefully handling errors or cancels from the user, I just > quit. > The script can be found at: > http://blogs.sun.com/clayb/resource/criteriaGUI.sh > > Thank you, > Clay > > On Thu, 30 Oct 2008, jan damborsky wrote: > >> Hi Clay, >> >> >> Clay Baenziger wrote: >>> Hi Jan, >>> Thank you for this fix it looks reasonable >> Thank you for reviewing those changes ! >> >>> (howevr I feel this is >>> the appropriate place to work with data as the webserver/database is data >>> agnostic and only deals with decimal, hexadecimal and string data). >> I might disagree with you in this point. The server side shouldn't be data >> agnostic as it encompasses the "human-machine interface" which processes >> the data obtained from user in form of XML document. As Dave already pointed >> out, >> it is not user friendly to expect the administrator to convert the criteria >> to the form underlying database can understand. So the server will be doing >> this conversion. >> >> Since it seems we are not agreement in this point, I think we should discuss >> it more again when revisiting that part of design specification. >> When the dust settles and 2008.11 release is out, could you please start >> discussion about this on caiman-discuss ? >> >>> Can you please see the code review for 4303, which will enable the >>> other criteria - as both changes need to go into ai_get_manifest.py and >>> are nearby eachother (webrev at >>> http://cr.opensolaris.org/~clayb/bug4303/webrev/)? >> The changes look good. Please also see my response to your >> code review request. >> >> Thank you, >> Jan >> >>> Thank you, >>> Clay >>> >>> On Wed, 29 Oct 2008, Jan Damborsky wrote: >>> >>>> Dave Miner wrote: >>>>> jan damborsky wrote: >>>>>> Dave Miner wrote: >>>>>>> Alok Aggarwal wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Wed, 29 Oct 2008, jan damborsky wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I please ask Clay and one more pair of eyes to take >>>>>>>>> a look at following AI stopper ? >>>>>>>>> >>>>>>>>> 4302 AI SC has to pad MAC addresses >>>>>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=4302 >>>>>>>>> >>>>>>>>> The webrev is available at: >>>>>>>>> http://cr.opensolaris.org/~dambi/bug-4302 >>>>>>>> It took me a few minutes to look up what zfill >>>>>>>> does but now that I know it pads a numeric string >>>>>>>> on the left with zeros, the fix looks good to >>>>>>>> me. >>>>>>>> >>>>>>>> Longer term (maybe even for 2009.04), I agree with you that it is >>>>>>>> better for the server to ensure it stores the mac address >>>>>>>> correctly. That's where this information originates from so that's >>>>>>>> where it should be stored in the desired format to start with. The >>>>>>>> client shouldn't have to guess. >>>>>>>> >>>>>>>> Could you perhaps add a comment in the code mentioning >>>>>>>> that this is a workaround until the server gets it >>>>>>>> right? >>>>>>>> >>>>>>> As I noted during review of the server, the manifest needs to be >>>>>>> modified to use natural representations, though the server can do >>>>>>> whatever it wants internally to obtain correct behavior. >>>>>> I think we should follow the same approach for the >>>>>> data transfered between client and server. This would >>>>>> help to make the communication better observable and >>>>>> avoid the need to have client and server in sync >>>>>> with respect to conversion algorithms applied, since all >>>>>> transformations would be done at one place. >>>>>> >>>>> Right, that's why I said "server" above. Canonicalize data in one >>>>> place, not multiple. >>>> I see - got it now :-) >>>> >>>> Thanks ! >>>> Jan >>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> >>
