> >> >> 1) what's the name you'd give this parameter? job-id? batch-id? > >> >> flow-id? command-id? correlation-id??? > >> > >> job-id will confuse us with engine's job-id which is a single > >> command > >> today. > >> correleation-id is pretty long and confusing as implies on > >> correlation > >> of something. > >> > >> I'm for flow-id or batch-id. > >> batch-id sounds the right one to me, as this is identifying a > >> batch > >> of > >> calls. > > >How about log-id? > >It isn't supposed to be unique, or of any format, it's just used to > >log calls, so log-id is the most natural (or log-tag or whatever > >name you prefer). > > > >Also I think it's more of a header-type parameter since it's > >metadata for the call, not an actual parameter that influences the > >outcome of the "flow". > > I actually believe you're right, it probably is better to pass this parameter > as > an http header. You've changed my mind about this (objections, anyone, to > passing > it as a header as opposed to passing it as a url parameter)?
Agree also that a header is much more natural in this case than a URL parameter. Also in the case where the client does not specify the ID themselves on the initial request, a generated value should be returned as response header (so that this can be passed as request header with the next request if part of the same over-arching task, or else just to aid log interpretation if the initial request was standalone but still mapped internally to multiple backend actions). > About log_id - it could sound like there are numerous logs, and the user is > asked > to specify the ID of the log he wishes to write to. But perhaps: log_entry_id? Is there any possibility that this identifier may be leveraged for uses other than log interpretation? One other suggestion to add into the mix: MetaTask-ID. Cheers, Eoghan _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
