Attendees
| IRC nick
|
Real name
|
| pnorman |
Paul Norman
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- changeset comments
- discussed schema changes to <changeset/> elements.
- using a GET parameter to enable comments isn't great, but is better than doing an API version bump just for this.
- imagery blacklist
- adding new XML nodes to the /capabilities call
- needs testing with existing editors on a branch
IRC Log
17:34:04 <zere> i probably had some stuff for teh agenda, but i've forgotten...
17:34:17 <zere> so anyone who wants to lead off the discussion?
17:36:05 <TomH> well changeset comments is the main thing I want to discuss
17:36:12 <TomH> are you now happy with the proposed api changes?
17:41:03 <zere> i haven't looked at the code since i made those comments, but yes - i'm happy enough with the GET parameter for including new API elements.
17:41:29 <zere> when 0.7 rolls around we'll just make that standard and ignore the GET parameter.
17:41:41 <TomH> and with the <discussion><comment>... structure?
17:42:08 <TomH> well if we're going to make it default why not do it now... it shouldn't break anything that uses a proper parser ;-)
17:42:55 <zere> sure, it'll break a whole bunch of pull-based parsers which are (as they should be) complaining about elements they don't understand.
17:43:34 <zere> if by "proper parser" you mean DOM, then yes, programs based on those shouldn't break.
17:44:23 <TomH> well you can ignore things you don't understand in either, or error on them in either ;-)
17:44:45 <TomH> but I thought the general idea of XML was to ignore things that you don't understand to allow for extension
17:45:14 <TomH> but sure, it's probably safer to have the param
17:49:03 <zere> it gets a bit murky when you can have multiple levels of nested extensions which then contain something you understand. sadly, most SAX/pull parsers aren't easily able to track that in a sane way and the most sensible thing to do is to error out when you don't understand something.
17:49:38 <zere> besides which it's technically a schema change within API 0.6, so it should be 0.7, but not worth breaking everything else for this ;-)
17:51:41 <TomH> well TBH I saw the flag more just as a way of not getting lots of discussion if you just need the changeset details
17:53:17 <zere> right. so i was a little bit worried that the text could potentially become quite large (i.e: legal-talk@ thread length)
17:53:17 * pnorman waves
17:53:36 <zere> but i guess we'll cross that bridge when we come to it
17:53:57 <zere> also, if the discussion takes >30s to render to XML, then it's probably write-only anyway
18:26:05 <zere> okay... if there's nothing else?
18:29:52 <pnorman> Any thoughts on how the DWG can get the blacklist feature added to capabilities? None of us code in ruby
18:49:23 <zere> it doesn't sound too complicated if you want to do it from the config, rather than in the database. i assume it won't be changing so often that a PR to add/remove a blacklist item will be onerous.
18:51:01 <zere> e.g: if you were to add an array (imagery_blacklist or something) at the end of https://github.com/openstreetmap/openstreetmap-website/blob/master/config/example.application.yml#L87 (with an appropriate comment, of course)
18:51:44 <zere> then add something to here: https://github.com/openstreetmap/openstreetmap-website/blob/master/app/controllers/api_controller.rb#L290
18:52:42 <pnorman> doesn't look *too* bad. I'll give it a shot
18:53:36 <zere> like "blacklist = XML::Node.new 'blacklist'\n IMAGERY_BLACKLIST.each |url_regex| { xnd = XML::Node.new 'if-match'; xnd['pattern'] = url_regex }\n api << blacklist" that would approximately work
18:54:09 <zere> oh, except "url_regex.to_s", just in case
18:54:24 <pnorman> tail -n1 \#osm-ewg.log >> rails_port
18:54:52 <zere> usually that wouldn't matter, but libxml-ruby is very sensitive to whether something is a string or not. stupidly, given that it could well call :to_s itself...
18:55:59 <zere> the difficult bit will be making sure editors have support for it (or at least don't break - see "proper parsers" above) before it goes live
18:56:39 <pnorman> JOSM is the one that tends to be strict, and it should support it (indeed, that's the entire point). But ya, need to test
18:57:04 <pnorman> Though we did add stuff to capabilities not too long ago, right? For read-only DB status?
19:02:22 <zere> yup, where "not too long ago" = april 2013 ;-)
19:03:32 <zere> i said "difficult", but it's only difficult in that someone has to check with the 5 or so "big" editors that they know it's coming and have somewhere to test against and sufficient fore-warning.
19:03:47 <zere> so, thanks everyone for coming & hope to see you next week :-)