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 >>
