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
> thanks,
> sarah
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
