Clay Baenziger wrote: > One comment, in-line. > > Thank you, > Clay > > On Mon, 15 Jun 2009, Sarah Jelinek wrote: > >> Hi Frank, >> >>> >>> >>> During AI processing on the client side, it asks the server for the >>> list of criteria the server is interested in from that client. The >>> server provides a list of criteria used(actually non NULL values) >>> for that service to the client. These non-NULL criteria could have >>> been published with independent AI manifests. If the client returned >>> criteria values that matched both of the published manifests, it >>> seems like we would get the 'default' manifest returned to the AI >>> client, since the manifests published were published with separate >>> criteria. That is a match on the 'AND' of the criteria requested >>> from the server would not match. (I believe this is the way the code >>> currently works). >> >> A correction on the last statement above... we actually will return a >> manifest that has a criteria that the client matches. According to Clay: >>> It iteratively adds new criteria into the query. So it'd match on >>> MAC address first (since it comes before memory in the database) and >>> then being that memory doesn't affect the one manifest matched it'd >>> allow that field to be NULL and return the MAC address based manifest. >> So, we would return a specific manifest, not the default one, and the >> ordering is based on the ordering of the publication of the criteria >> and manifests in a service. > > The ordering is currently based on creation of the fields in the > database, as the fields created first have a higher precedence. From > usr/src/cmd/ai-webserver/Makefile (line 87) we see the ordering is > (first to last): > arch, mac, ipv4, cpu, platform, network, mem
Thank you for the clarification Clay. sarah ***** > >> thanks, >> sarah >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
