Attendees
| IRC nick
|
Real name
|
| gravitystorm |
Andy Allan
|
| RichardF |
Richard Fairhurst
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
| Zverik |
Ilya Zverev
|
Summary
- API 0.7
- Zverik has put up a list of features on his wiki page.
- Some discussion about the motivation for a few of the items on there, but generally deemed to be details.
- ACTION: zere to set up an api07 branch (both rails_port and cgimap, with issue trackers, plus an apis.dev.osm.org running instance).
- Some discussion over whether it would be better to write new code in cgimap or rails_port. Consensus seems to be for the former.
- bug reporting improvements
- Background: Rob Nickerson was kind enough to report that it's difficult to find where (on the wiki) various bits of software have links to their trackers.
- Concentrate on improving the bugs page.
IRC Log
17:32:13 <zere> minutes of the last meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2014-06-23
17:32:14 <Zverik> hi :)
17:32:26 <Zverik> I've read the minutes, they are good. Thanks
17:32:30 <zere> please take a look and let me know if there's anything in the minutes which needs changing.
17:32:37 <zere> Zverik: great, thanks :-)
17:33:15 <zere> topics on today's agenda: API 0.7 (incl. parent links), and bug reporting improvements.
17:33:27 <Zverik> I noticed that a lot of tasks go to pnorman's todo list
17:34:29 <zere> i think pnorman only committed to the CI one. the benchmarking for cgimap i think was more of a "would be nice if" thing.
17:34:59 <zere> and i'm sure he doesn't mind if anyone else wants to have a go at them :-)
17:35:15 <Zverik> is anyone else here btw? :)
17:35:52 <zere> well, gravitystorm joined just before the meeting started. RichardF and TomH are probably lurking too.
17:36:11 <gravitystorm> yep, I'm here
17:36:51 <Zverik> I'd like to push api 0.7 forward. I polished the list of small features: http://wiki.openstreetmap.org/wiki/User:Zverik/API_0.7_Proposal
17:37:10 <zere> #topic API 0.7
17:38:00 <Zverik> we don't have to implement them or any other features right away, but I think we have to at least make the impression the work has started
17:38:15 <Zverik> e.g. make the branch and lay a policy for adding features
17:39:29 <zere> okay, that's got a lot longer since the last time i read it.
17:39:41 <zere> that tends to happen with API 0.7, though ;-)
17:41:00 <Zverik> most of those features were being requested for years again and again. I can shorten it even more, but this way it could server as a "top 15 tasks", like that wiki page we had
17:41:12 <Zverik> *serve
17:41:58 <zere> just because something has been requested doesn't mean it's either good or feasible.
17:42:09 <zere> for example: that's not how If-Modified-Since works
17:42:34 * RichardF is here
17:43:33 <zere> If-Modified-Since means: if the document hasn't been modified since that date, return 304 Not Modified. it's not for filtering. if we wanted filtering it would have to be a ?since= parameter
17:43:47 <zere> which overpass is much more suited to, imho.
17:45:19 <Zverik> okay, sounds reasonable
17:45:31 <Zverik> I had doubts myself about that item
17:46:26 <zere> i'm not sure about the restrictions on keys & values either... what's the issue which is driving that?
17:48:15 <Zverik> quite a lot of issues with various editors. Some expect trimmed keys, some break when there are exotic characters in relation roles
17:48:45 <zere> then they're broken?
17:49:10 <zere> i mean: that's a bug in the editor, not something that needs to be fixed in the API, surely?
17:49:28 <zere> one man's "exotic" character is another man's native character set
17:50:34 <Zverik> yes, but the reasoning for those validations is different. By this time tagging principles have become more or less stable: ascii keys, [a-z]* roles, no spaces before or after values. Taginfo marks deviations from that as errors, and...
17:51:05 <Zverik> ... new editor authors will forget such rare cases where role is actually a unicode, for example
17:51:11 <zere> from those taginfo stats, it seems like ~33% of keys don't match that regex
17:52:09 <Zverik> zere: that's because there is probably no digits for [A] in taginfo
17:52:53 <zere> i'm not convinced of that line of argument... for example: if we make decisions based on what new editor authors might forget, then perhaps we need to just use ASCII?
17:53:39 <Zverik> well, what about 0x00-0x20 ascii?
17:54:03 <zere> what about them?
17:54:41 <Zverik> and if we decide not to have them in keys, we are starting to pick out characters, and while we're at it, we can also disallow some more
17:54:43 <Zverik> zere: http://en.wikipedia.org/wiki/Ascii#ASCII_control_characters
17:55:12 <zere> we already don't (apart from \t, \r and \n) because they're invalid characters in XML
17:55:41 <zere> now, imho, that's XML being broken, but unfortunately it's both a historical and external constraint
17:55:55 <Zverik> but still, we are getting carried away with details, like in previous discussions about api 0.7. You cannot solve every problem by dispelling them, and this topic is not about which items in the proposal are godd and which are not
17:56:14 <Zverik> s/godd/good/
17:56:55 <zere> okay, so about the branch and decision procedure for getting stuff onto it.
17:57:03 <Zverik> yup
17:57:09 <zere> i can set up a branch, that's no problem.
17:57:15 <zere> #action zere set up api07 branch
17:57:25 <zere> the issue will be getting stuff onto that branch :-)
17:57:38 <Zverik> I'm at loss here, because I haven't contributed a single byte to rails-port and don't know ruby (yet)
17:58:02 <zere> well... so gravitystorm and i were talking (at the pub, best place to solve problems)
17:58:13 <Zverik> also, policy. Which features we consider "worthy", and what a PR needs to have to be merged (docs, tests, etc)
17:58:36 <zere> the alternative to doing it in the rails_port is to do it in CGImap
17:58:52 <zere> and run 0.6 (rails_port) and 0.7 (CGImap) in parallel.
17:59:15 <zere> the advantage of this is that CGImap already has a fairly complete JSON implementation that you can test today
17:59:25 <zere> and the beginnings of a "tiled" map call.
17:59:54 <zere> the disadvantage is that its API coverage is pretty thin.
18:02:15 <Zverik> are there /api/0.6 calls that are still being processed by rails port, and can we move them all to cgimap?
18:02:36 <zere> anyone know if, on github, issues can be assigned to branches? or do you have to manually apply tags for those things?
18:02:37 <Zverik> those are basically database requests converted to xml/json, right?
18:02:49 <Zverik> only with tags, alas
18:03:15 <TomH> yes there are calls still being run by rails
18:03:20 <TomH> all the history calls to start with
18:03:31 <zere> yeah, most of the 0.6 calls are still going through rails_port. it's pretty easy to convert the current_* API calls, but the historical ones will require more effort.
18:03:34 <TomH> and trivial things like capabilities and the user call
18:03:51 <TomH> plus the write calls of course ;-)
18:05:02 <zere> in my opinion, i'd prefer to move in the direction of CGImap - i'm just not sure that it's less effort overall. and given the point of excluding "big" things like areas is to move a bit quicker, it might be counterproductive
18:05:10 <Zverik> so basically... we can forget rails port for time being and just make cgimap an official 0.7 repo
18:05:28 <Zverik> so "cgimap for everything" would be another feature of 0.7
18:05:33 <TomH> my goal is to move the api to cgimap certainly
18:05:52 <zere> okay... then i guess i'd better try and sort it out.
18:06:26 <zere> the two major blockers there are the lack of upload support (basically OAuth) and lack of history support
18:06:36 <RichardF> Zverik: I think that's fixed your amf_controller issue ;)
18:07:04 <Zverik> cgimap is here? https://github.com/zerebubuth/openstreetmap-cgimap maybe move it to osm project?
18:07:23 <zere> actually, i tried to support AMF format in CGImap... but i failed to grok the format :-)
18:07:33 <zere> RichardF: i would take a patch ;-)
18:08:27 <zere> Zverik: you mean, here? http://git.openstreetmap.org/cgimap.git/
18:09:34 <Zverik> if only you could make PRs there and have some page for issues...
18:09:57 <zere> what's the problem with having those things at the maintainer's repo?
18:10:15 <Zverik> no problem, I guess
18:11:16 <Zverik> so, I see there is a directory for 0.7 code. Does it mean 0.7 won't require a branch?
18:11:40 <zere> indeed. one of the benefits^W brain-damages of the C pre-processor :-)
18:12:26 <zere> there's a configure flag, --enable-api07, which turns that code on
18:14:34 <Zverik> so... we are slowly coming to a point where we decide that nothing actually has to be done to enable working on api 0.7 :)
18:15:02 <Zverik> and the only thing we need is more C++ programmers
18:15:09 <zere> possibly. we'll have to see how it goes. i'd love to get some patches :-)
18:15:29 <zere> but unfortunately programmers seem to be thin on the ground - either of the ruby/rails or c++ varieties.
18:17:23 <zere> okay... let's see how it goes. we can come back to this next time.
18:17:36 <zere> #topic bug reporting improvements
18:17:55 <Zverik> I wonder if there are any ruby/c++ programmers who left wishes on api0.7 wiki page (sorry)
18:18:30 <zere> Rob Nickerson noticed that there's no good place (on the wiki) to find where to report a bug, and still many references to trac, which is mostly abandoned.
18:18:54 <zere> most OSM-related projects have their issue trackers on github nowadays...
18:19:42 <zere> so the question is: can we make a page which brings together all the information (at least for the more prominent projects), or have some better way to guide people towards the appropriate place?
18:19:45 <Zverik> http://wiki.openstreetmap.org/wiki/Bugs — the first outer link, for example
18:21:06 <Zverik> first and obvious question: which kind of bugs? By those most users mean "my POI doesn't get rendered"
18:21:56 <Zverik> and obvious answer, I guess, would be to make a wiki page (or reuse "Bugs" one) for listing issue trackers for every kind of bug
18:23:11 <Zverik> zere: did Rob provide an example of a bug? Or was it just a general suggestion?
18:24:22 <zere> i think it was in general - he noticed that https://wiki.openstreetmap.org/wiki/How_to_contribute links to trac under the "testing" section.
18:24:41 <zere> and thought we should elaborate.
18:27:17 <zere> i created https://wiki.openstreetmap.org/wiki/Testing
18:27:39 <zere> if anyone (nudge RichardF) would like to help with that, it would be greatly appreciated!
18:28:18 <RichardF> testing is, um, probably not my area of expertise
18:28:47 <zere> but writing helpful documentation is! :-)
18:29:00 <Zverik> maybe instead of "Testing" make it "Reporting bugs"?
18:29:11 <Zverik> "Report bugs", since "Contribute data"
18:30:57 <zere> ok, done
18:31:12 <zere> also changed "software development" -> "develop software"
18:31:54 <Zverik> great. I can put some direct links with explanations there later. Current list seems unfriendly
18:32:01 <zere> so now this page needs making better https://wiki.openstreetmap.org/wiki/Bugs
18:35:29 <zere> okay, we'll revisit again later to see what could do with more improvement.
18:35:33 <zere> #topic AoB
18:35:54 <zere> i'm not going to be around next monday (7th July)
18:36:23 <zere> does anyone else want to chair the meeting?
18:36:32 <zere> gravitystorm: nudge, nudge
18:37:02 <gravitystorm> zere: sure, I can do it next week
18:37:10 <zere> gravitystorm: great, thanks :-)
18:37:21 <zere> anyone else have anything else they'd like to talk about?
18:38:24 <Zverik> I don't
18:38:48 <zere> okay, cool. thanks to everyone for coming!
18:38:55 <Zverik> thanks!
18:39:22 <zere> hope to see you on the 14th, but gravitystorm will be here on the 7th for the next meeting