On 22.11.2013, at 11:30 , Robert Kisteleki <robert@ripe.net> wrote:
Hello,
But anyway. My wishes have been stated a few times now, do what you want with it.
Since this thread is also about quotes: "There's no problem in Computer Science that can't be solved by adding another level of indirection to it"
I propose a middle ground here (between "UDMs are immutable" and "I need a stable ID anyway") -- labels.
The user specifying a UDM would be able to attach one (ore more?) labels to it, like "Ping to Gert's network". Then this label can be used in access functions, like data downloads, where instead of an ID, you ask for the label; the result is a union of all the measurements with that label. In other words, a label is a kind of ID that stays the same across multiple measurements.
Would this work for you?
Regards, Robert
What is needed from my point of view: - make it possible to define a new measurement copying any parameter that makes remote sense from an existing measurement - int API and GUI, API more important - allow filtering in the API based on 'owner' and 'description' This way one can create a series of related measurements and find them back by a common description tag. No new field is needed. Just make existing ones searchable in the API as they are in the GUI. What would be nice to have is a forward/backward link chain of these measurements, e.g. enumerate measurements based on this msmid enumerate measurements this msmid is based on. Daniel