This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
- Previous message (by thread): [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
- Next message (by thread): [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gilles Massen
gilles.massen at restena.lu
Mon Dec 23 18:55:26 CET 2013
On 23/12/2013, 17:19 , Stephane Bortzmeyer wrote: >> I could live with non-public data becoming public a few days after >> the measurement, > > One of the goals of the new policy is to simplify the Atlas code and > documentation. What you suggest would add new code and complexity. Over making everything public, certainly. Compared to the current public/private distinction the additional complexity looks negligeable (naively I'd say replace the private flag with a timestamp that will expire - added complexity: one cron job, and a few queries to adapt). However it would meet the other goal: make all data public and thus avoid duplicate jobs. Anyway, making jobs private (forever or temporarily) means a lot to me, and so I would be willing to tolerate quite some complexity (I know that I'd hardly feel the cost personally...) Best, Gilles
- Previous message (by thread): [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
- Next message (by thread): [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]