On Fri, Oct 02, 2015 at 11:43:30AM -0700, Priya Ahuja wrote: > Thanks for the changes. Is there a reason for keeping pre-set > structured data elements like timeQuality, tzKnown if custom data is > provided? I don't think uses want to generate things like timeQuality by shell on logger command line. IMHO "--sd-id timeQuality" will be used very rarely (but it's possible and supported use case). The another thing is that we already released logger with build-in timeQuality and we have to keep it for backward compatibility. > Also if the SD-ID is the same, it would make more sense > merging the structured data into one, what do you think? You have to use unique SD-ID and use it only once. It's pretty simple semantic, I'm not sure if need something more complicated/complex. (Or do you mean something else?) For example: --sd-id zoo@123 \ --sd-param tiger=\"hungry\" \ --sd-param zebra=\"running\" \ --sd-id manager@123 \ --sd-param onMeeting=\"yes\" sd-id command line option works as separator between the elements, so it generates two SD-ELEMENTS: [zoo@123 tiger="hungry" zebra="running"] [manager@123 onMeeting="yes"] Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
