what I meant

[git.ikiwiki.info.git] / doc / plugins / osm / discussion.mdwn

diff --git a/doc/plugins/osm/discussion.mdwn b/doc/plugins/osm/discussion.mdwn
index 5736a24305c27c5a3b5dd46703f6ed0d13df090f..ff3cb8d36b131de507661a5058c8f2067d25b30c 100644 (file)
--- a/doc/plugins/osm/discussion.mdwn
+++ b/doc/plugins/osm/discussion.mdwn
@@ -71,6 +71,31 @@ rather not have to carry around a local copy of his work to get a map
 with waypoints on my HTTPS site. [[smcv]], can you spare some round
 tuits to give us your thoughts? --[[schmonz]]
 
 with waypoints on my HTTPS site. [[smcv]], can you spare some round
 tuits to give us your thoughts? --[[schmonz]]
 

+> I've never used the osm plugin, so I don't know how well it works at the moment.
+> I think the lack of test coverage has been a significant factor in it not actually
+> working. Even if we don't have test-driven development, the next best thing is
+> bug-driven testing: every time something regresses, we should have a test that
+> asserts it doesn't fail like that again.
+>
+> If the current osm plugin is at all usable, then we'd need to look at the specific
+> ways in which the new one is incompatible, but if the current osm plugin doesn't
+> actually work anyway, then the new one can't break working sites...
+>
+> Determining whether there's HTML injection is certainly an important thing to
+> review. We need to be able to say what's trusted, what's attacker-controlled, and
+> what was originally attacker-controlled but has been sanitized or escaped and
+> hence has reached a trusted state.
+>
+> As an upstream developer, I would say that my preferred approach to Leaflet would
+> be to vendor it and use the vendored copy by default, but have a configuration
+> parameter to load it from a CDN instead. In the Debian package, to avoid the
+> situation we've got into with jQuery where we have a vendored copy that we
+> don't dare to update to a new version because we don't know what it will break,
+> I think there should be a dependency on libjs-leaflet and a dpkg trigger to
+> copy its files into our underlay (ideally we'd symlink it, but ikiwiki doesn't
+> follow symlinks, and I don't think an approach to symlinks in underlays that
+> isn't a security flaw is going to happen any time soon). --[[smcv]]
+

 ----
 
 Just stumbled onto this. 
 ----
 
 Just stumbled onto this. 


@@ -95,3 +120,5 @@ I've done some initial testing now and I'm wondering if behaviour has changed wi
 
 >>> What I meant was that you could add a wiki link (to a page with a map) next to each waypoint to simulate the old behaviour. 
 >>> Maps with subsets of waypoints, waypoint in multiple maps: no, because a single GeoJSON file is created for each "map". But something that could be added is the ability to merge multiple maps into one view, as separate layers. --[[users/tincho]]
 
 >>> What I meant was that you could add a wiki link (to a page with a map) next to each waypoint to simulate the old behaviour. 
 >>> Maps with subsets of waypoints, waypoint in multiple maps: no, because a single GeoJSON file is created for each "map". But something that could be added is the ability to merge multiple maps into one view, as separate layers. --[[users/tincho]]

+
+>>>> A wiki link to a map page will show the whole map zoomed out I presume so that won't be helful when I have pois across the globe and you want to know which side of a building the photo is taken from :( Merging maps would be a very good feature! If it could be done with a pagespec type thing it would be awesome. For my use case I could then have a map at each building page showing the locations of all the photos under that page. The map file would be reasonably small. If these maps could then be merged via a directive with globbing of some sort into a mega-map that would be a very flexibly solution that automatically updates when I add new maps (buildings). I just need to use my non-existent programming skills to force my hack plugins into automatically creating per album maps.  -[[users/kjs]]