Feature #377
Add the equivalent of sname for <mp />s in XML config
| Status: | Closed | Start date: | 01/09/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Jolyon White | % Done: | 100% |
|
| Category: | client | |||
| Target version: | 2.6.0 |
Description
Consider the following excerpt:
<mp name="video" samples="1">
<f pname="id" />
<f pname="psnr" />
</mp>
<mp name="video" interval="1">
<f pname="id" fname="delta" sname="delta-frame-d" />
<f pname="psnr" />
<f pname="psnr" fname="stddev" sname="psnr-stddev"/>
</mp>
Two things happen to the same mp:
1. The measurements are stored verbatim for each sample,
2. Some of them are filtered to extract the metrics at a given frequency.
Doing so, one ends up with two different measurements with names video andvideo_2. Though they are easily identified, it is not obvious which one's
which.
It would be better to be able to specify “user-friendly” names by doing something like the following.
<mp name="video" samples="1">
<!-- rest here... -->
</mp>
<mp name="video" interval="1" mpname="video-processed">
<!-- rest here... -->
</mp>
Related issues
| related to Feature #435: Allow users to disambiguate measurement streams from diff... | New | 23/09/2010 |
Associated revisions
Add ability to control stream names in client config XML
- Added <stream mp='foo' name='bar'/> to allow creating a stream
named 'bar' from an mp named 'foo'. If the 'name' attribute is
left out, the stream is named after the MP.
- In old config format, added 'rename' attribute to achieve the same
thing. The above is equivalent to <mp name='foo' rename='bar'/>.
- Note that the 'name' discussed above is actually concatenated with
the app name to generate the final MStream name (which appears as
a table name in the database).
- The old behaviour was to append a '_<n>' to the name to avoid name
clashes, where <n> is an incrementing integer. This behaviour is
no longer supported. Name clashes now cause the configuration process
to abort with a message to the user. (This type of implicit behaviour
makes it harder for users.)
- Fixes #377.
History
Updated by Jolyon White over 1 year ago
I think this problem comes about because the configuration file format deals in the wrong concepts. In this particular case, the <mp /> element is misnamed. It should be called <stream /> because it is used to create measurement streams, not measurement points. So we should make it look something like this:
<stream name="video" samples="1" /> <stream name="video-processed" mp="video" interval="1" />
In this case, the "name" attribute names the stream, not the MP. If no name is given, use the MP of the same name as the input to the stream. In the second case, we explicitly identify the MP to use as the input because there is no MP with the same name as the stream ("video-processed").
Updated by Olivier Mehani over 1 year ago
Jolyon White wrote:
If no name is given, use the MP of the same name as the input to the stream.
As we discussed before, maybe the name of the created field should always get the filter that processed it appended to its name in order to facilitate differentiation and avoid schemata conflicts between similar measurements with <i>e.g.</i> different sample or interval propoeties.
Updated by Jolyon White 10 months ago
- Category set to client
- Status changed from New to Closed
- Assignee set to Jolyon White
- Target version set to 2.6.0
- % Done changed from 0 to 100
Implemented now on master. The new <stream/> element supports a name attribute that gives the name of the stream, as it will appear in the database. For instance, the following will create a stream from MP abc, call it foo and result in a database table called myapp_foo, where myapp is the application name:
<stream mp="abc" name="foo" samples="1"/>
For backwards compatibility, the old equivalent of <stream/>, namely <mp/>, still exists and now supports a rename attribute for the same purpose:
<mp name="abc" rename="foo" samples="1"/>
achieves the same thing as above.
The old name clash auto-avoidance is gone; if your config file results in two streams having the same name, the configuration process aborts and you get an error message telling you about the problem in the log file.